Information management system

ABSTRACT

An information management system is described comprising one or more workstations running applications to allow a user of the workstation to connect to a network, such as the Internet. Each application has an analyser, which monitors transmission data that the application is about to transmit to the network or about to receive from the network and which determines an appropriate action to take regarding that transmission data. Such actions may be extracting data from the transmission data, such as passwords and usernames, digital certificates or eCommerce transaction details for storage in a database; ensuring that the transmission data is transmitted at an encryption strength appropriate to the contents of the transmission data; determining whether a check needs to be made as to whether a digital certificate received in transmission data is in force, and determining whether a transaction about to be made by a user of one of the workstations needs third party approval before it is made. The analyser may consult a policy data containing a policy to govern the workstations in order to make its determination.  
     The information management system provides many advantages in the eCommerce environment to on-line trading companies, who may benefit by being able to regulate the transactions made by their staff according to their instructions in a policy data, automatically maintain records of passwords and business conducted on-line, avoid paying for unnecessary checks on the validity of digital certificates and ensure that transmissions of data made by their staff are always protected at an agreed strength of encryption.

BACKGROUND OF THE INVENTION

[0001] This invention relates to the provision of extended managementfunctionality for Internet applications, particularly in the areas ofinformation security, transaction auditing and reporting, centralizedpolicy, and application connectivity.

[0002] Electronic commerce (“eCommerce”), particularly betweenbusinesses (“B2B”), but also between business and consumers (“B2C”), isa fast growing market where buyers and sellers communicate using theInternet, a worldwide network of linked computer systems, instead of bytraditional means such as mail, telephone and personal meetings. Sellersadvertise products and services using digital brochures and catalogues,which can be viewed or downloaded via an Internet connection, throughpages on the World Wide Web, or via electronic marketplaces typicallydealing in the goods and services of a particular market sector. Buyerscan find suppliers, select goods, obtain quotations, place and trackorders, and even make payments entirely electronically and at any time.eCommerce brings the promise of increased flexibility, choice andefficiency, with dramatically reduced procurement costs.

[0003] There are two universally accepted means of interfacing users tothe Internet. The first of these is the ‘Web Browser’ which allows usersto view pages on the World Wide Web by accessing individual web sites,the addresses of which are typically widely published either usingtraditional means, or are referenced in another web site. The mostwidely adopted web browser is Microsoft Corporation's “InternetExplorer”.

[0004] The second means of interfacing is using an Electronic Mailprogram, with which the user composes a message, known as an e-mail,which is then electronically routed to the address of the intendedrecipient over the Internet. Well known Electronic Mail programs includeIBM Corporation's “Lotus Notes” and Microsoft Corporation's “Outlook”.

[0005] In a typical eCommerce scenario, a buyer might identify aparticular product, together with pricing and delivery information, onthe sellers' web site. He may then place an order, either by filling inan electronic order form on the web site, or by sending an e-maildirectly to the seller. The order would typically include a commitmentto payment, perhaps in the form of Credit Card details, or by someelectronic payment means. The seller would then typically send a returne-mail to confirm acceptance of the order.

[0006] Web Browsers operate in accordance with recognized standards, inparticular Hyper Text Transfer Protocol (“HTTP”), described fully inInternet standards document RFC2616. Electronic Mail programs operate inaccordance with recognized standards, in particular Simple Mail TransferProtocol (“SMTP”), described fully in Internet standards documentRFC0821 and Multipurpose Internet Mail Extensions (“MIME”) describedfully in Internet standards documents RFC2045-2049.

[0007] While eCommerce provides enormous benefits, its adoption raisesmany new issues, which must be addressed in order to ensure itscontinued adoption, particularly if it is to ultimately replacetraditional methods. One of the central issues is security.

[0008] The Internet is an open communications network, which is bydefinition insecure since anyone can use it.

[0009] Means to secure sensitive information to be exchanged over theInternet (for example in an eCommerce transaction) have been provided bythe adoption of secure transmission protocols and messaging. Securepoint to point transmission protocols, used for example between a webServer and a web Browser, include the ‘Secure Socket Layer’ (“SSL”),defined by Netscape Communications Corporation, and its successor‘Transport Layer Security’ (“TLS”) defined in Internet standardsdocument RFC2246. Secure e-mail message standards include ‘SecureMultipurpose Internet Mail Extensions’ (“S/MIME”) described fully inInternet standards document RFC2633 and “Pretty Good Privacy” a publicdomain secure messaging system developed by Philip Zimmerman.

[0010] In order to control access to information on servers connected tothe Internet, a system of usernames and passwords has been widelyadopted. For example, access to discounted price lists on a particularweb server may be restricted to trade users who have previously beengiven a username and password allowing them access. Similarly, on-lineinformation services typically make extensive use of usernames andpasswords to restrict access to those who have paid for the service. Byproviding each user with a unique username and a changeable password,the service can ensure that only paid subscribers can access the system,and allow users to prevent access by others to their personal datastored by the service.

[0011] In eCommerce applications, a major problem is the issue ofidentity and trust. When a supplier receives an order via the Internetit is perfectly possible, even likely, that he has no prior knowledge ofthe customer. The supplier must establish that the customer is a) who hesays he is, in other words that he is not masquerading as someone else,and that b) he is to be trusted and will ultimately pay for the goods orservice to be supplied. These issues have been addressed in the B2Cmarket principally by the use of credit cards. The customer provides hiscredit card number and address with the order, which the supplier thenverifies with the credit card company, and obtains authorization for thecharge. The entire process is typically carried out on-line withouthuman intervention. This method is largely effective where a supplierships goods to the cardholder address, since a potential thief would notonly need to steal the cardholders details, but would also need tointercept delivery of the goods. It is much less effective in the caseof services where no physical delivery is involved.

[0012] Clearly, the use of credit cards in eCommerce, though widespread,is restricted to small-scale transactions potentially involving amounts,say, up to $10,000. For those transactions above such amounts (which inaggregate monetary terms far exceed those below them), a mutuallytrusted third party must be used to establish both identity and trust.

[0013] Central to establishing identity is the use of DigitalCertificates. The customer can be issued with a Digital Certificate by atrusted third party, which is then used to electronically ‘sign’communications. On receipt of a signed message, the recipient (in thiscase the supplier) can positively establish a) the identity of thesender, b) that the message has not been altered, and c) that the sendercannot subsequently deny he sent the message. Recognized standards forDigital Certificates are described in ITU document X.509, and their usein Internet communications in Internet standards documents RFC2312,RFC2459, RFC2510, RFC2511, RFC2527, RFC2560, RFC2585 and RFC2632.

[0014] Chargeable, Third party services, such as that provided byValicert Inc., can be used to verify that a Digital Certificate has notbeen revoked, for example after the certificate has been compromised insome way.

[0015] Once authenticity of messages is established, the supplier canuse another third party to establish trust, or the same third party canbe used to establish both authenticity and trust. For example‘Identrus’, a consortium of the world's major banks, provide a systemsuch that when a supplier receives a message signed with an Identrusissued Digital Certificate, he can independently verify that thecustomer is a valid account holder in good standing with a recognizedbank.

[0016] Ultimately the system is to be extended such that the bank willadditionally warrant the transaction, thereby guaranteeing payment tothe supplier. It will be appreciated that the terms ‘customer’ and‘supplier’ can apply to any two parties engaged in Internetcommunication.

[0017] It can be seen that appropriate combinations of the systemsdescribed provide a secure foundation for use of the Internet and theservices and functions available through it. However, we haveappreciated that there are a number of problems with conductingeCommerce using only these systems. These problems are discussed below.

[0018] In the secure transmission protocols and messaging referred toabove, data is usually encrypted before transmission and decrypted bythe intended recipient prior to viewing. Thus, should the data beintercepted during transmission, it will be safe from viewing byunauthorised third parties unless they know or can ascertain the secretencryption key of the encryption algorithm.

[0019] The encryption and decryption of data at each end of a securelink or message requires significant processing power. Additionally bothtransmitting and receiving parties must be in possession of the sameencryption key of the encryption algorithm, at the same cryptographicstrength, in order for the system to operate successfully. This oftenpresents a problem, for example where regulations for the import orexport of data into or out of a computer system prohibit the use ofhigher strength algorithms, forcing the link or message to be encryptedat a lower cryptographic strength, or preventing secure communicationsat all. Consequently, secure links and messaging are typically used onlywhen necessary.

[0020] In the case of communications over the World Wide Web, therequirement to secure transmissions is determined and initiated by theweb Server. If, for example, the server is about to transmit an orderform for completion by the user it may initiate a secure link such thatthe order information will be encrypted when transmitted back to theserver. Similarly, once the order is complete the server may terminatethe secure link and return to normal unencrypted communication.

[0021] Typically, the only indication the user has that a link has beensecured is an icon (usually depicting a padlock), which appears in thebrowser window. Once the icon has appeared, the user can then typicallyinterrogate the browser to determine the strength of the encryptionalgorithm being used, and can decide whether or not to enter, andsubsequently transmit sensitive information, such as his credit card andaddress details.

[0022] In practice however, users frequently do not check that the linkis secure, far less that it is of suitable cryptographic strength toprotect the information being transmitted. In order to address thisproblem, e-mail applications such as Microsoft Corporation's “Outlook”provide the ability to encrypt all e-mails by default.

[0023] The wide adoption of usernames and passwords has created amanagement problem for many Internet users due to the sheer number thatneed to be remembered, particularly when good security practice requirespasswords to be frequently changed. Similarly, users will often need touse a variety of different usernames since someone else may already havetaken their ‘favourite’ at a given site. Facilities to remember, and toautomatically complete username and password fields on subsequentoccasions, have been provided in web Browsers such as MicrosoftCorporation's “Internet Explorer”, and by add-on ‘helper’ utilities suchas Gator.com's “Gator”. These facilities typically maintain a file ofusernames, passwords and the web page to which each applies. These filesare encrypted to ensure that only the appropriate user can access them.If such username and password files are lost or become unavailable, suchas when the authorised user has forgotten the encryption key or can nolonger be contacted to provide it, or when the file is accidentally ormaliciously lost, destroyed, or corrupted then access to Internetaccounts and services may be lost, and each site must be approachedindividually to replace or recover the necessary username and/orpassword. This can be a very expensive problem for corporations in termsof lost access and administrative time. Additionally, such rememberedusernames and passwords are only available for use on the machine onwhich they were originally used. If the user moves to another machine,or uses multiple machines then the stored usernames and passwords areunavailable to him from those other machines.

[0024] All businesses, and many individual users, have a legalobligation to maintain accurate records of the transactions theyundertake, but for eCommerce transactions this can prove difficult.Businesses must keep records for auditing purposes, for example to provethe terms upon which goods were ordered in the event of a dispute. Suchrecords are considerably more difficult to maintain in an eCommerceenvironment, requiring the user to retain, for example, copies of orderssent by e-mail, or to print out the web page receipt from a web sitepurchase. For the user, this is labour intensive and there is noguarantee that any such created records are complete or reliable.

[0025] One automated solution of keeping records of eCommercetransactions is provided by Max Manager Corporation's “Max Manager”application. Max Manager captures receipt pages at known web sites,extracts transaction information from those receipt pages, and thenstores locally both the receipt page and the extracted transactioninformation on the machine on which the application is running. However,in order to operate, Max Manager must be supplied with the exact addressand layout of the receipt page. Max Manager determines that an eCommercetransaction has taken place either by detecting the address of thereceipt page, or by comparing the current page being viewed by a browserwith the layout of the receipt page that it has been supplied with. Onceit has identified a receipt page, the relevant transactions details areextracted from the receipt page by using the known layout of the page asa template for matching purposes. A significant drawback with MaxManager is that it may only be used to extract data from those pages forwhich it has been supplied with details. Moreover, if the layout of thereceipt page is changed then Max Manager cannot meaningfully extract anydata from the page until it is supplied with a new template for thechanged layout. Since web sites change frequently, Max Manager must beconstantly updated to take account of such changes. This is impracticalon a large scale and inevitably leads to transactions being missed, orworse reported incorrectly.

[0026] Problems also stem from the fact that computer terminals aredistributed, often resulting in terminals and users being located atdifferent locations. In multi-user environments, user machines may bephysically connected to each other, for example using a Local AreaNetwork (“LAN”), which provides a gateway for connection to theInternet. They may also be connected to local servers such as MicrosoftCorporation's “Exchange Server”, which acts as a central collection anddistribution point for e-mail messages, and Microsoft Corporation's“Proxy Server”, which acts both as a cache to improve performance offrequently visited web Sites, and as a filter to prevent access tocertain web Sites which may have been designated as undesirable.However, in so far as the exchange of information is concerned, exceptin the case of a message sent between two local users, each useroperates entirely in isolation from others at the same location. Thispresents a significant management problem for corporate and otherorganizations, which have no means of centrally controlling employeeactivity and cannot benefit from the significant cost savings that mightbe made from the sharing of information. For example, two users in anorganization may independently receive e-mail messages digitally signedby the same sender. Both recipients must separately validate the DigitalCertificate, incurring two validation charges, at least one of which wasunnecessary.

[0027] The present invention provides additional functionality to thesystems mentioned above to alleviate their inherent problems and toprovide a single integrated system for information exchange.

SUMMARY OF THE INVENTION

[0028] The invention is set forth in the independent claims to whichreference should now be made. Advantageous features of the invention areset out in the appendant claims.

[0029] The information management system provides many advantages in theeCommerce environment to on-line trading companies, who may benefit bybeing able to regulate the transactions made by their staff according totheir instructions encoded in the policy data, automatically maintainrecords of passwords and business conducted on-line, avoid paying forunnecessary checks on the validity of digital certificates, and ensurethat the transmission of data by their staff is always protected at anagreed level of encryption.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The preferred embodiment of the invention will now be describedin more detail, by way of example, and with reference to the drawings inwhich:

[0031]FIG. 1 is a schematic illustration of the present arrangement ofsystems and resources making up the Internet according to the prior art;

[0032]FIG. 2 is schematic illustration of the preferred embodiment ofthe invention implemented in a corporate environment;

[0033]FIG. 3 is a schematic illustration of the operation of a webbrowser in accordance with the preferred embodiment of the invention;

[0034]FIG. 4 is an illustration of a typical input window generated by aweb browser;

[0035]FIG. 5 is a schematic illustration of the operation of an e-mailclient in accordance with the preferred embodiment of the invention;

[0036]FIG. 6 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, forcapturing username and password values transmitted by a user to a remoteweb site;

[0037]FIG. 7 is an illustration of example policy data specifyingcontrol conditions for recording data;

[0038]FIG. 8 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, forrecognizing credit card numbers contained in data transmitted to or froma web server or e-mail client;

[0039]FIG. 9 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, forestablishing the validity of a digital certificate received by a user;

[0040]FIG. 10 is an illustration of example policy data for determiningwhether or not a digital certificate should be verified;

[0041]FIG. 11 is a flowchart illustrating how the example policy datashown in FIG. 10 is used to determine whether or not to verification isrequired for a digital certificate;

[0042]FIG. 12 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, foridentifying transmissions from a user or to a user that comprise part ofan eCommerce transaction;

[0043]FIG. 13 is an illustration of example policy data intended to beused with the process illustrated in FIG. 12 to identify a transaction;

[0044]FIG. 14 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, forrecording transmissions identified as comprising part of a singletransaction thereby forming a record of the transaction ;

[0045]FIG. 15 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, forapproving or rejecting identified transactions on the basis of apredetermined policy setting; and

[0046]FIG. 16 is an illustration of example policy data for determiningwhether an identified transaction requires approval, and for identifyingan appropriate approver;

[0047]FIG. 17 is a flowchart illustrating the operation of a plug-inmodule, according to a preferred embodiment of the invention, fordetermining an appropriate level of encryption for a transmission andallowing that transmission to be transmitted only if that level isprovided; and

[0048]FIG. 18 is an illustration of example policy data specifying therequired encryption strength for various data types.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0049] The preferred system provides users of the Internet with anautomatic way of managing the flow of information on a computer system.It provides facilities to manage the security level at whichtransmissions occur, facilities to record on-line transactions and torefer transactions that are about to be made to third parties forapproval, and means to stop transactions from occurring if approval isrefused; it also provides facilities to extract and record pertinentdata from any transmissions that are received or are about to betransmitted.

[0050] The preferred system provides solutions for many of the problemsencountered by eCommerce companies trading over the Internet;consequently the following exemplary discussion will be directed mostlyto the implementation and use of the system by a company of reasonablesize conducting at least some of its business over the Internet. It willbe appreciated that anyone however, including companies of any size ordescription and private individuals, who use the Internet may benefitfrom the functionality provided by the preferred system.

[0051] The functionality of the preferred system is implemented throughmodules of code which are ‘plugged-in’ to the web browser or e-mailclient. These ‘plug-in’ modules may be used to control and alter thebehaviour of the web browser or e-mail client in operation.

[0052] Many existing web browsers and e-mail clients may already bereadily integrated with such plug-in modules. In the case of Microsoft'sInternet Explorer, the plug-in is known as a ‘Browser Helper’, and ismore fully described in the document “Browser Helper Objects: TheBrowser the Way You Want It” by Dino Esposito, published by MicrosoftCorporation in January 1999. In the case of Microsoft's Outlook andExchange e-mail Clients, the plug-in is known as an ‘Extension’ and ismore fully described in the document “Microsoft Outlook and ExchangeClient Extensions” by Sharon Lloyd, published by Microsoft Corporationin March 1998. The use of the ‘Browser Helper Object’ and ‘Extension’plug-ins made in the preferred system will be described in more detaillater.

[0053] The use of browser or e-mail client plug-in modules to implementthe functionality of the preferred system has the additional advantagethat, since encryption of message content is usually carried out by thebrowser or e-mail client itself, examination of transmission content, toextract password information or to determine the desired level ofencryption for example, may take place before the content has beenencrypted ready for transmission, or indeed after it has been receivedand unencrypted.

[0054]FIG. 1 shows the relationship between service providers, typicallycompanies selling goods and services over the Internet 10, and userswishing to purchase such goods or services. Users equipped with webbrowsers 22, 24 and 26, can connect via the Internet and retrieve webpage information from web servers 14 and 18. Alternately users withe-mail applications 20, 30 and 32, can send and receive e-mail messageswith abc.com and xyz.com via e-mail servers 12 and 16.

[0055] In a corporate set up, such as that which is illustrated in thebottom right hand corner of FIG. 1, web browsers 24 and 26 of acorporate user are connected to the Internet via proxy server 28. Theproxy server 28 is used to cache web pages and control access to websites. Similarly, the corporation has e-mail clients 30 and 32,connected to the Internet via e-mail server 34 which acts as a centralcollection point for e-mails coming into the corporation and whichcontrols distribution of the e-mails to individual users. It will beappreciated that while FIG. 1 describes abc.com and xyz.com as sellers,a corporation can be both a buyer and a seller, and as buyers abc.comand xyz.com would be described as corporate users for the purpose ofthis description.

[0056] In the case of e-mails sent and received by personal e-mailapplication 20, it should be noted that the mail will typically becollected and distributed by a remote e-mail server provided by thesupplier of the Internet connection service to which the personal usersubscribes.

[0057] While many of the features and functions of this system provideconsiderable benefit to an individual user, the system provides themaximum advantage when operating in a multi-user environment wheretransaction information is gathered from many users. FIG. 2 shows aschematic diagram of the preferred configuration of the system in amulti-user environment. The preferred system comprises a CentralManagement server 40 connected to a database 42 and operator consoles44. The Central Management Server 40 is also connected to Back OfficeApplication Plug-ins comprising Application Interfaces 50, 52 and openApplication Program Interface 54, and to Gateway components 60, 62 and64. Gateway component 62 is shown as connected to User ApplicationPlug-ins, located on one or more user's machines, comprising InternetExplorer Plug-in 70, Netscape Navigator Plug-in 72, Microsoft OutlookPlug-in 74, and Lotus Notes Plug-in 76. These plug-ins are used providethe functionality of the preferred system in the hosting program inwhich they are integrated. Four possible hosting programs are shown,Internet Explorer, Netscape Navigator, Microsoft Outlook and LotusNotes, but any other program with the capability to connect to theInternet may also be used, providing its behaviour can be modified toimplement the functionality of the preferred system.

[0058] Connection to the Internet 10 is made via the User applicationplug-ins and their respective hosting programs.

[0059] The gateway components 70, 72 and 74 are optional but arepreferred as they enable the entire system to scale, with each gatewaystoring and forwarding information, thereby allowing any number of usersto be connected.

[0060] Information from the multiple application Plug-Ins 70, 72, 74 and76 for the different applications on multiple user machines is gatheredby the central management server 40 and stored in an associated database42.

[0061] The Back Office Application Plug-Ins 50, 52 and 54 allow thesystem to interface with third party management applications such asorder processing and accountancy systems. This allows transactioninformation to be automatically entered and processed by such systems.

[0062] Operator Consoles 44 are provided for administrative purposes,and in particular for the approval of transactions. While logicallydepicted as directly attached to the central management server in FIG.2, such consoles could be run on any networked machine. Where an e-mailor web browser plug-in determines that a particular transaction requiresapproval, a request is sent to the Central Management Server and queuedpending approval by an authorized operator.

[0063] The operation of the system is controlled by policy data, whichstores the corporation's regulations regarding security, authorisation,and the actions that user's are permitted to perform, as well asoperating information. Preferably, the policy data is stored in a policyfile on the central Management Server for access by any of the OperatorConsoles 44, Back Office Application Plug-ins or User ApplicationPlug-ins. The system administrator or network supervisor may define oneor more policies or settings of the policy file and may assignindividual users or groups of users to different policies, thuscontrolling a user's ability or even a workstation's ability to interactwith the Internet without the need to set parameters and controlsdirectly at each user's machine. A user in the accounts department of acompany for example may be assigned to an ‘accounts policy’; anysubsequent change to that policy will then automatically result in achange in the capabilities of all users assigned to that policy.

[0064] It is preferred that the capability to edit or set the policydata is restricted to the network supervisor or other authorised personor persons. This may be achieved by designating one or more supervisorworkstations in the network enabled with access to edit the policy datasuch as Operator Consoles 44.

[0065] Preferably, the policy is tree-like in structure, allowingsettings to be forced down to individual policy nodes of the tree, andglobal changes to be rapidly made, for example if the CEO wishes tocause all purchases to require his approval if company cash flow shouldbecome a problem. Such a policy based system greatly reduces the latencyinherent in both traditional purchasing systems and in current eCommercepurchasing environments.

[0066] Each user of the network will have his or her own representationof policy data. Preferably, only the branches and leaves of each user'spolicy that differ from a master network policy are stored as thisallows space in memory to be saved. Although the policy data ispreferably stored in file form on the Central Management Server, it isnot intended that storage of the policy data be restricted to file formonly. Any other representation or encoding of policy settings may beemployed within the preferred system.

[0067] The implementation of the system in a web browser or in an e-mailclient will now be described in more detail.

Use of the Preferred System in a Web Browser

[0068]FIG. 3 shows the simplified operation of a web browser. The webbrowser is launched at step S100 in response to a start request fromeither the user or automatically from the start-up file of the user'scomputer. The start-up file contains commands to automatically runspecified programs when the computer is booted-up. After the web browserhas been started it typically requests a ‘home page’, the default webpage for viewing, in accordance with a pre-determined setting. This isshown at step S102.

[0069] The request is sent to the appropriate web server 90, the exactInternet address of which usually being determined by Domain NameServices; the web server 90 then replies with the appropriate datadefining the web page. This process is represented respectively as stepsS104 and S106 which result in step S108.

[0070] The data defining the web page consists of HTML script, and otherpossible data types such as XML or ActiveX, and Javascript which encodesexecutable programs. The Browser interprets this data, displaying and/orexecuting it as appropriate at step S110.

[0071] The browser then typically waits for user input at step S112.Such input may include filling displayed fields, clicking on ahyper-link, or entering the URL address of a new web page. Ultimately,such actions lead to a further request being sent to the web server 90at step S114 and step S116. The request may simply be another web pageaddress, or it may contain additional data such as that typed in todisplayed fields by the user.

[0072]FIG. 4 shows a sample web page display, in which a GUI ispresented to the user in order to receive the users name and e-mailaddress. It will be seen from reference to FIG. 4 that the user hasentered his name as ‘Fred Smith’ into the name request field provided,and his e-mail address as ‘fsmith@xyz.com’ into the e-mail addressfield.

[0073] When the user clicks the ‘Submit’ button provided on the requestwindow, the details the user entered are included in the command sent tothe web server 90. Such a command might be:http://www.sample.com/sample2.htm?UserTD=Fred+Smith&emai1=fsmith@xyz.com&submit=submit

[0074] It can be seen from the above that the user's name isincorporated into the command as the value of a variable called ‘UserID’and his e-mail address is incorporated as the value of a variable called‘email’.

[0075] The command is assembled in step S114, and transmitted to the webserver 90 in step S116 where the user name and e-mail addressinformation may be used, for example, to send product information to theuser via e-mail, or to gain access to other web pages.

[0076] The plug-in module provided by the preferred embodiment of theinvention in the form of a Browser Helper Object (BHO) providesadditional functionality to augment that of the standard web browser.The BHO is implemented to respond to a number of significant events thatoccur as the web browser is operated and directed by the user tointeract with various web sites and pages.

[0077] The BHO is implemented to monitor navigation requests and datasubmitted to the web server from the browser and identify data that isunique to the user. It may do this simply by searching the outbound datastream for the presence of pre-determined words or phrases. In the abovecase shown in FIG. 4, the two variable definitions ‘UserID’ and ‘email’may be searched for, and the data that follows them extracted andstored. Alternatively, the BHO may search for the ‘?’ symbol, whichindicates the end of the URL address being connected to and indicatesthat what follows is data. The BHO may also monitor the inbound datastream received from the web site being connected to.

[0078] Also, the BHO may be implemented to monitor the operation of theweb browser itself. As the web browser operates it generates ‘events’ tonotify co-dependent software modules or objects that somethingsignificant has just occurred or that an action has just been completed.The name of the event is usually descriptive in its own right of whathas just occurred; additional data that describes the event in moredetail is normally available. The BHO is implemented to trap theseevents and to take action in dependence on them.

[0079] One such event that the BHO is implemented to respond to iscalled ‘BeforeNavigate’ which the web browser fires when the userrequests the browser navigates to a new page. The event is issued andmay be recognised by the BHO before the requested page is downloaded,allowing the BHO to take any pertinent action before the user views thepage. One such action might be to record the page and any data submittedin response to that page in a database. Another such action might be toidentify the URL of the requested page from the event and prevent thepage being downloaded.

[0080] Another event that the BHO traps is the ‘DocumentComplete’ event,which is fired by the web browser when a new page has been fullydownloaded from the web site into memory. The page is encoded in theform of a Document Object, conforming to Microsoft's Document ObjectModel (DOM). The DOM provides comprehensive access to the datacomprising the page, allowing the BHO to extract data items which are ofinterest to it. For example, the BHO may request data from the DOM todetermine whether the page forms part of an eCommerce transaction. Itmay do this by searching objects in the DOM for terms such as ‘Receipt’or ‘Account Number’.

[0081] The BHO may also use the DOM to determine the field names orfield types of data being requested on a web page. The data entered bythe user into such fields may then be extracted from the DOM and storedor acted upon. Field names are typically descriptive of what is stored;passwords, for example, are often held in a field called ‘password’ andso may be searched for on a web page. Credit card numbers may besearched for in a similar way. Usually, password fields are of a typesuch that any entered data is displayed as asterisks. This too may bedetermined from analysis of the DOM and used to identify pertinent data.

[0082] User data would not normally be present in a web page downloadedfrom a web site, but would be entered by the user into an HTML form.Usually, the potentially sensitive user data is transmitted to the website via the web server when the user selects a ‘Submit’ button. At thisstage, the BHO can trap the ‘Submit’ event issued by the web browser,and access the DOM to extract the user data, and, if necessary, preventthe data from being transmitted.

[0083] Encryption and decryption on a secure link will take place afterpoint C and before point A in FIG. 3 respectively. Thus, the BHO mayanalyse the data before it is encrypted or after it is decrypted. Thisis advantageous since there is no need for the BHO to perform anyencoding or decoding of data itself. This does not affect the ability todetermine if the link is secure or not, since a secure link can beidentified by the protocol identifier “https” at the beginning of thecurrent URL. It is preferred that examination of the transmission'scontent take place before encryption or after decryption occurs.

Discussion of the Operation of an E-mail Client

[0084] With reference to FIG. 5 of the drawings, the operation of atypical e-mail client, and the implementation of the preferredembodiment in an e-mail client will now be described.

[0085]FIG. 5 shows the simplified operation of an e- mail client.Receive and Send operations typically operate independently, and theseoperations are shown separately on opposite sides of FIG. 5, beginningat steps S120 and steps S130 respectively.

[0086] An e-mail client's ‘receive message’ operation is initiated atstep S120. This may be done automatically at predetermined intervals inorder to keep the user informed of any new messages that he hasreceived, or it may be done in response to the user manually selecting a‘receive messages’ icon. Starting this operation causes the e-mailclient to poll the e-mail server 95 and download any new messages to theuser's machine. In step S122, an e-mail message is received by thee-mail client. Typically, when a new message is received, it is added toan ‘Inbox’, with the received message headers (senders name, date andtitle for example) arranged in a list. The user then clicks on theappropriate entry in the list to read the full message causing it to bedisplayed on his computer screen. The e-mail message is displayed atstep S124.

[0087] In the case of an outgoing e-mail, the user selects a ‘composee-mail’ option as step S130. In response, the e-mail client provides aninterface comprising a text editor in which the user can enter the textof the body of the message and other information such as destinationaddress, subject and so on. The user composes the message in step S132and then opts to send it, by selecting an icon or menu option providedby the e-mail client to issue a ‘send command’. The e-mail is sent tothe e-mail server for transmission to the recipient in step S134. If anyencryption is applied by the e-mail client it is applied in step S134before transmission.

[0088] In the preferred embodiment, additional functionality is providedfor the e-mail client via a plug-in module. Preferably, the e-mailclient is one of those provided by Microsoft, such as the MicrosoftExchange client, or the Microsoft Outlook client, and the plug-in moduleis encoded as an Exchange client extension. These are described in thedocument “Microsoft Outlook and Exchange Client Extensions” by SharonLloyd mentioned earlier.

[0089] An Exchange Client Extension is a component object that complieswith the Microsoft Windows Component Object Model (COM) and thatutilizes the Exchange IExchExt interface. This interface provides anumber of additional interfaces for modifying the operation of theExchange e-mail client, such as the IExchExtCommands interface, whichallows existing client behaviour to be replaced or modified and newcommands to be added to the client's menus; and the IExchExtEventsinterface which allows custom behaviour to be implemented to handleclient ‘events’ such as the arrival of new messages, reading, writing,sending messages and reading and writing attached files. TheIExchExtMessageEvents, IExchExtSessionEvents and theIExchExtAttachmentEvents interfaces are also provided and provideadditional functionality for the more specific tasks that each of theinterfaces names suggest.

[0090] In the preferred embodiment, the Exchange Client Extension thatforms the plug-in module is implemented to respond to client ‘events’that are fired by the client program as it performs operations andcompletes actions. The ‘events’ in question are provided by the COMinterfaces mentioned above. The monitoring of the e-mail client by theplug-in module may therefore be seen to be analogous to the way in whichthe BHO plug-in module monitors the operation of the web browser.

[0091] The e-mail client plug-in module is implemented to respond to the‘OnDelivery’ event for example which is fired when a new message isreceived from the underlying mail delivery system and before it isvisible to the user. The ‘OnDelivery’ event contains information toaccess the different parts of the e-mail message that have beendownloaded and which are held in memory. The message header, the messagebody and any message attachments are encoded in memory as properties ofthe message object which may be separately accessed through MailApplication Program Interface (MAPI) calls.

[0092] Via the information supplied as part of the ‘OnDelivery’ event,the plug-in module may access the message header and extract theidentity of the sender for example. Furthermore, the plug-in module mayutilise information obtained from MAPI calls to scan the body of areceived message for keywords or pertinent data. It may search forevidence of an eCommerce transaction, by identifying significant wordssuch as ‘receipt’ or ‘account number’. The message may then be storedfor auditing purposes. In the case of an unapproved sender, or harmfulmessage content, the message may be deleted unseen.

[0093] The analysis of a received e-mail occurs therefore at point A inFIG. 5 prior to being viewed by the user. Preferably the e-mail isexamined before the e-mail is even placed in the Inbox. Where a messageis not automatically decrypted before being placed in the Inbox, forexample where the user is required to enter a decryption key, themessage is examined immediately following decryption, but beforeviewing. Digital Certificates may be included as attachments to thee-mail and can readily be examined prior to viewing, allowing anyappropriate actions, such as validation, to be performed.

[0094] Another significant client event that the plug-in module isimplemented to respond to is the ‘OnWriteComplete’ event which is firedwhen the user has selected the ‘send command’ and requested the e-mailclient to transmit a new e-mail message to the mail delivery system.This event is fired, at point B in FIG. 5, before the transmission andbefore any encryption takes place. The new message which is to betransmitted is similarly stored in memory as an object which may beaccessed by MAPI calls. The plug-in module may use the MAPI calls toscan the content of the outgoing e-mail for sensitive data, such ascredit card number, and consequently cause the message to be recorded oreven blocked.

Plug-In Module Operation

[0095] The preferred implementation of the web browser and e-mail clientplug-in modules has been described above with reference to FIGS. 3 and 5above. Next, the functionality provided by the plug-in modules will bedescribed in detail and with reference to FIGS. 6 to 18.

Identifying and Recording Usernames, Passwords and other Information

[0096] The preferred system provides means to automatically identify,collect and store data contained in transmissions to and from a user'sworkstation, in particular, the usernames and passwords entered by auser to access web site pages, File Transfer Protocol (‘FTP’) sites andother such sites on the Internet.

[0097] Systems that presently provide facilities to record passwordscurrently only do so when a user a clicks on the ‘remember password’,option provided on the GUI. The password is saved into a protected localfile on the user's machine that is only opened when the user isauthenticated on that machine, for example, by entering his username andpassword at boot time. The remember password option causes the system toremember the user's password when he next visits, pre-filling in thepassword field with that password so that the user does not have toenter it each time it is required. The drawback of the password filebeing stored locally is that if the user moves to another machine hedoes not have access to the stored password file and will have tore-enter the password himself.

[0098] The preferred system identifies passwords automatically, withoutthe need for instruction from the user, and stores the identifiedpasswords and usernames in a data repository. Preferably this is centraldatabase 42. This allows the passwords of any user to be recalledregardless of the terminal at which the user logs on, providing theterminal has access to the central database.

[0099] Any identified passwords and usernames are stored in the databasealong with the field names in which they are stored on the original website and the address of the Internet site to which they were transmittedto and at which they are used. Site information can be retrievedstraightforwardly as it is included in the HTTP request submitting thepassword and username information to that site, and in therepresentation of the web page held in memory.

[0100] Preferably, for the sake of security, the information stored inthe database is encrypted, so that only a select number of people, suchas network supervisors, system administrators or company directors haveaccess to it. They may access the database either through a workstationin the network, by entering a username or a password to identifythemselves, or through a supervisor workstation, such as OperateConsoles 44.

[0101] This storage of usernames and passwords along with addressdetails presents a significant advantage to companies that use on-linefacilities. With existing technologies, if a user forgets hisauthenticating password preventing access to the protected file, orleaves the company without having disclosed it, the Internet servicecannot be accessed. A similar situation occurs if the protected file isdamaged, deleted or otherwise lost. Each Internet service must then beapproached in order to replace or recover the lost password, which canbe expensive both in terms of lost access and administrative time. Withthe preferred system, the password information may be recovered from thecentral database, so that access to web sites is not lost.

[0102]FIG. 6 is a flow diagram which schematically illustrates theoperation of a plug-in module implemented to extract user name andpassword information from data to be transmitted to a web server.

[0103] In step S150, the plug-in module begins and parses the data aboutto be transmitted to the web server from the browser. This occurs atpoint ‘C’ in the process illustrated in FIG. 3. Control then passes tostep S152 where the plug-in module determines whether or not the datawhich is to be transmitted contains username or password information.

[0104] The passwords and usernames may be identified in the mannerdescribed above with reference to FIGS. 3, 4 and 5, by identifying fieldnames in submitted command or by using the DOM, for example, to searchfor field names, field types, or the display method used to identify thedata on web pages. They may also be retrieved from the HTML of webpages, the pop-up windows or GUIs (Graphical User Interfaces) presentedby remote servers or providers on the World Wide Web or even by scanningthe content of e-mail messages.

[0105] Identifying passwords and usernames in transmitted commands or inthe DOM of a web page from their field names relies on those field namesdescribing their purpose with obvious labels such as ‘password’ or‘username’. In cases when the field names are not themselves meaningful,the nature of data being transmitted, may be inferred from the fieldtype of the data, that is ‘String’, ‘Integer’ and so on, or the displaymethod used to enter the data. Fields that are intended to receive apassword can be identified from the representation in by searching for a‘password’ field type in the DOM. Text boxes on a web page into whichpassword data is to be entered, for example, typically display eachcharacter input as an asterisk; this property may be determined from theDOM and used to infer that data input into the text box is a passwordeven if there are no other indications. Although, the password isdisplayed as a string of asterisks, the representation in memory stillcontains the character information that was entered by the user. Thepassword may then be retrieved simply by extracting the input from thefield.

[0106] Alternatively, passwords and usernames may be identified byreferring to those stored by other programs such as Microsoft's‘Internet Explorer’ when the remember password option is selected by theuser. Such passwords are stored in a local protected file on the user'scomputer. This file is ‘unlocked’ when the user is authenticated on thecomputer, and so may be accessed to obtain password and usernameinformation by the browser plug-in module of the preferred system.

[0107] If the plug-in module does not detect a username or a password inthe data which is to be transmitted, control passes to step S158 atwhich point the module exits and control is passed back to point ‘C’ inFIG. 3. The browser may then transmit the data to the web server. Ifhowever, a username or a password is detected by the plug-in module atstep S152 then control passes to step S154, where the values of theidentified username or password and the URL or other identifier of theweb page to which the data is to be transmitted are extracted. Controlthen passes to step S156 where, these values and the URL or otheridentifier are stored in a predetermined system database 42. Oncestorage has taken place, control then passes to step S158, where themodule exits and control is passed back to point ‘C’ in FIG. 3. Thebrowser may then transmit the data to the web server.

[0108] The preferred embodiment need not be limited only to the storageof passwords or usernames which have been used as an example because ofthe immediate advantage that their storage provides. Other types ofdata, in particular those relating to eCommerce transactions, such ascredit card information and digital certificate may also be usefullyextracted and stored to provide a database or record. The system forextracting information from transmissions may also be applied to e-mailsystems.

[0109] The information may be extracted in the manner described above,via the DOM or via MAPI calls to the COM representation of e-mailcontent, or may be extracted from the language in which a web page isencoded. Web pages are typically encoded in Hyper-Text Mark-Up Language(HTML), a human readable text based language which may be searched forknown key words or indicators using conventional text matchingtechniques. In the preferred embodiment, recording of the data mayinvolve recording just password and username information, recording theURL of a web page being viewed or of an e-mail account, recording anydata submitted to the fields of a web page, and recording the HTML of aweb page, so that the web page may be retrieved later and viewed.

[0110] The plug-in modules provided by the preferred system operate inconjunction with policy data, which may be recorded in a file, database,or software code for example. The policy data provides a user of thepreferred system to instruct the operation of each of the plug-inmodules thereby controlling their functionality.

[0111] A sample representation of policy data, illustrated in FIG. 7,shows how a user may control the operation of the plug-in module torecord password and username information along with other types of data.

[0112] The tree-like structure of the policy data is clearly seen inFIG. 7 which shows just one major branch of the policy data entitled“Recording”. The Recording branch is separated into two sub-branchescalled “Browser” and “Email” which contain instructions for theoperation of web browser and e-mail client plug-in modules respectively.

[0113] The browser branch contains three sub-branches called“DataToRecord”, “WhenToStartRecording” and “WhenToStopRecording”. TheDataToRecord branch specifies the type of data that is to be extractedfrom transmissions to or from the user's workstation and a web server.Four types of data are referred to in the illustration, these being theURL of the web page being viewed, the HTML of the web page being viewed,data that is entered by a user into fields provided on the web page andsubmitted to a web site, and any passwords and usernames that areentered by the user. These are referred to on four distinct sub-branchesof the DataToRecord branch, entitled “URL”, “HTML”, “SubmittedFields”and “Passwords”. A Yes/No option on each of those sub-branches specifieswhether or not the indicated data is to be recorded.

[0114] The WhenToStartRecording branch sets out a number of conditionswhich specify the point at which the data specified in the DataToRecordbranch is to be recorded. Five conditions are illustrated in thisexample each one set out on a separate branch and respectively entitled“WhenBrowserIsOpened”, “IfCreditCardNumberSubmitted”,“IfPasswordSubmitted”, “IfKeywordsReceived” and “IfKeywordsSent”.Whether or not these conditions are to be used in order to determinewhen to start recording is indicated by Yes/No markers on each branch.

[0115] Similarly, the WhenToStopRecording branch lists three conditionsthat may be used to determine the point at which the recording of thedata specified in the DataToRecord branch is to be stopped. Theseconditions are “WhenUserClosesBrowser”, “WhenUserChangesSite” and“WhenUserChangesPage”. The Yes/No status of each of the conditions andfor each of the type of data to be recorded may be easily set by a userof the preferred system in order to control the operation of the plug-inmodule.

[0116] The e-mail branch of the policy data is divided into aDataToRecord branch and a WhenToRecord branch. Each of these branchesare sub-divided into branches that deal with Sent Mail and ReceivedMail. The type of data that may be recorded is set out in theDataToRecord branch and for sent mail may be the message text, anyattachments to the message, and in the case of messages signed with adigital signature, a copy of the digital certificate accompanying thesignature. Conditions for recording sent mail and received mail are setout in the WhenToRecord branch and may be based on the identification ofa credit card number, a keyword or a digital certificate in the mailthat is sent or received.

[0117] The tree-like structure described is the preferred form for thepolicy data since it allows the data to be easily organised and referredto. It also allows different users to be assigned to different branchesof the tree in order to receive different policies. Although, the treelike structure is preferred, other arrangements may also be possible.The branches shown in this diagram are only intended to be illustrative.

Identification of Credit Card Numbers

[0118] The preferred system also searches for Credit Card numbers orother account information in the data to be transmitted to the webserver or e-mail client by searching for a string of numeric digits,typically between 14 and 16 long. It then determines if the string ofdigits passes one of the tests universally used by credit card companiesto validate card numbers. If a credit card number is found in thetransmission, then the preferred system may take a number of actionsdepending on the settings in the policy file, such as refer thetransmission to a third party for approval, renegotiate a higher levelof encryption to safe-guard the transmission if the credit card numberbelongs to the company, or prevent the transmission from taking placealtogether.

[0119] The most common test to identify a credit card number is definedin ANSI standard X4.13, and is commonly known as LUHN or Mod 10.

[0120] The Luhn formula is applied to credit card numbers in order togenerate a check digit, and thus may also be used to validate creditcards, in which case the check digit is figured in as part of theformula. To validate a credit card number using the Luhn formula, thevalue of every second digit after the first, starting from the righthand side of the number and moving leftwards, is multiplied by two; allof the digits, both those that have been multiplied by two and thosethat have not are then added together; any digit values that have becomegreater than or equal to ten as a result of being doubled, are summed asif they were two single digit values, eg: ‘10’ counts as ‘1+0=1’, ‘18’counts as ‘1+8=9’. If the total of the sum is divisible by ten, then thecredit card is a valid credit card number.

[0121]FIG. 8 is a flow diagram which illustrates the operation of aplug-in module which detects credit card numbers, using the Luhn formuladescribed above, in data which is about to be transmitted. If a creditcard number is identified, the plug-in module implements furtherpolicy-based checks, based on the outcome of which, the plug-in modulemay determine to transmit the data containing the credit card number orto prevent transmission.

[0122] The module begins operation at step S160, which follows point ‘C’in the process illustrated in FIG. 3 in the case of browserimplementation, or point B in the process illustrated in FIG. 5 in thecase of an e-mail client implementation. Control passes from step S160to step S162 in which the module scans the data about to be transmittedto the web server or e-mail service and extracts from it a first stringof digits that is likely to be a credit card number.

[0123] This is achieved by scanning the data comprising the transmissionfor strings of digits over a particular number of digits long. Creditcard numbers are usually made up of more than 12 digits, and are notusually more than 16 digits long. Thus any strings of digits in thisrange may be identified as possible credit card numbers.

[0124] Following the extraction step S162 control passes to decisionstep S164 where a routine end of file check is made. If the datacontains no candidate credit card number and the end of the file checkis reached before any first candidate number could be found, then atstep S164 control passes to step S178 where the transmission of the datais allowed to proceed without any further checks being made. The modulethen exits at step S180. Control resumes in the web browser operationshown in FIG. 3 from point ‘C’ or in the e-mail client operation shownin FIG. 5 from point B.

[0125] If a first potential credit card number is found in the data instep S162, then it is extracted and stored in memory. The end of filehas not been reached yet so control passes from step S162 to step S164and then to S166 where a checksum for the stored candidate number iscalculated using the Luhn formula. Control then passes to decision stepS168, where the checksum is queried.

[0126] If the checksum indicates that the candidate number is not avalid credit card number then control passes back to step S162 where thenext potential credit card number is extracted from the data. If asecond credit card number is not found, then the end of the file isreached and control passes to step S178 where the transmission isallowed to proceed, and then to step S180 where the module exits.

[0127] However, if the checksum indicates that the candidate number is avalid credit card number then control passes to decision step S170 wherethe settings of the policy data are queried for the appropriate actionto take. The action may be determined from such factors such as thenumber itself, the identity of the user transmitting the number and theaddress to which it is to be sent. The policy data might for examplespecify that credit cards are not to be transmitted, or that a higherencryption strength is required for the transmission before it mayproceed.

[0128] This policy checking step allows credit card transactions to becontrolled at a higher level than the user making the transaction. Thusfinancial decisions may be swiftly and easily implemented, and may beenforced automatically without the need for monitoring. An organisationmay, for example, wish to restrict the capability to make credit cardtransactions on the organisation's account to particular authorisedpeople or it may wish to restrict transactions on a particular accountaltogether.

[0129] In step S170, the credit card number, and other details of thetransaction are compared to the settings in the policy file and it isdetermined whether or not transmission may take place. If for anyreason, with reference to the policy checks, it is determined that thecredit card number should not be transmitted, control passes to stepS172 where transmission of the data is halted, and then to step S174where the module exits. At this point the system could notify the userthat the request has been denied by means of a pop-up message box.Control then returns to point A in FIG. 3, in the case of a web browser,or to step S132, ‘compose mail’ in FIG. 5, in the case of an e-mailclient.

[0130] If in step S172, it is determined that the credit card number maybe transmitted, control passes to step S176 where transmission of thedata occurs, and then to step S180 where the module exits. In this casecontrol is resumed from point C in the web browser operation illustratedin FIG. 3, or from point B in the e-mail client operation illustrated inFIG. 5.

[0131] Credit card numbers need not be identified in step S162 solely byscanning the content of the transmission. In web browser implementationsthe credit card number may for example be directly identified byreferring to the field names of any variables that are to be transmittedor also from the representation of the web page in memory. Thediscussion above about the identification of passwords explains this inmore detail.

[0132] The preferred system may also be configured to search outgoingtransmissions for other pertinent financial details, such as accountnumbers. Company account numbers from which funds may be deposited maybe stored in a separate file. Any likely strings of characters or digitsmay then be extracted from the outgoing data in the manner described andcompared with the entries in the accounts file to determine whether ornot it is a valid account number. The transaction may then be allowed toproceed or be refused in the manner described above. Although creditcard numbers have been referred to, it will be appreciated that any typeof card number for making payment such as debit card numbers may also beused.

[0133] Also, although identification of credit card numbers has beenexplained with reference to data that is to be transmitted, it will beappreciated that similar techniques could be used to identify andextract credit card numbers from transmissions that are being received.

Validation and Authentication Support

[0134] On-line transactions typically require some form ofauthentication that the user is who he says he is, and that he is ableto pay for the goods ordered. These requirements are usually met by thepurchaser supplying the trader with his credit card number and thecardholder address which can then be verified by the seller with thecard issuer. Increasingly however, Digital Certificates are attached toelectronic transmissions by the user which, in conjunction with adigital signature, allow the receiver to verify that the transmissionoriginated from the person named as sender. Digital certificates fromcertain issuing authorities, such as Identrus, may also act as awarranty that the holder will honour his commitment to pay a specifiedamount of money. These certificates are useful when trading on-line.

[0135] Digital signatures are a widely used means of establishing anindividual's identity on-line when transmitting information or whenconducting a transaction. They also provide a guarantee to a recipientof any transmitted information or transaction details that those detailsand that information have not been tampered with en-route by anunauthorised third party.

[0136] Digital certificates are issued to individuals, organisations, orcompanies by independent Certificate Authorities, such as Verisign Inc.An organisation may also act as its own Certificate Authority issuingits own digital certificates which may or may not be derived from a‘root’ certificate issued by another Certificate Authority. A digitalcertificate typically contains the holder's name, a serial number, anexpiration date, a copy of the certificate holder's public key and thedigital signature of the certificate issuing authority. A private key isalso issued to the certificate holder who should not disclose it toanyone else.

[0137] Certificates are unique to each holder and may be revoked by anissuer if the holder is no longer viable; alternatively, a holder mayask to have it revoked if his private key has been compromised.

[0138] The public and private keys may both be used in tandem to encryptor decrypt a message. Anyone may use a certificate holder's public keyto encrypt a message so that it may only be read by the certificateholder after decrypting the message with his private key.

[0139] Messages may also be digitally signed using software whichconverts the contents of the message into a mathematical summary, calleda hash. The hash is then encrypted using the sender's private key. Theencrypted hash may then be used as a digital signature for the messagethat is being transmitted. The original message, the digital signatureand the transmitter's digital certificate are all sent to a recipientwho, in order to confirm that the message he has received is completeand unaltered from its original form, may then produce a hash for thereceived message. If, the received hash, having been decrypted with theholder's public key, matches the hash produced by the recipient, thenthe recipient may trust that the message has been sent by the person towhom the certificate was issued, and that the message has not beenaltered en route from its original form. Digital certificates aretherefore of considerable and increasing importance to companiesconducting business on the Internet.

[0140] In cases where an on-line trader makes use of DigitalCertificates to ensure the identity of its customers, it is necessary tocheck with the issuer that the certificate is still valid before anytransaction is authorised. Such checks can be carried out on-line usingan independent verification service such as that provided by Valicert,Inc. A fee is usually charged for such services.

[0141] It may be that individual employees of an organisation eachreceive e-mails from a single client, each signed with his digitalcertificate, on separate occasions. Presently, there is no way for ainformation about certificates received by one employee to be sharedwith another employee unless they share it themselves manually, and as aresult, individual employees might request that the same certificate bevalidated each time that they receive it. This is wasteful however,since once a certificate is revoked by its issuer, it is never againreinstated, so any validation fees spent on an already revokedcertificate are unnecessary. Additionally, the recipient may wish tomake a business judgement as to whether a previously validatedcertificate should be re-checked or not. For example, if a digitallysigned order for $1M worth of goods is received one day, and thecertificate successfully validated, and on the next day another orderfor $50 is received, signed with the same certificate, the organisationmay consider a second validation check to be unnecessary, thereby savingthe validation charge.

[0142] The preferred system provides means to record information aboutthe Digital Certificates that have been received, the status of thecertificate at the last check as well as, where applicable, transactioninformation, such as client, amount, date, goods and so on. Thisinformation is stored in a central database to which all users of thesystem have access. The preferred system also provides means to use thestored information to decide whether or not a validation check isdesirable, and to accept or refuse transmissions depending on the statusof the digital certificate. Thus, users of the system may receive andreview transmissions without the need to establish their authenticitythemselves.

[0143]FIG. 9 illustrates the operation of a plug-in module of thepreferred system implemented to extract digital certificates fromtransmissions received by company employees and record them in adatabase along with their validity status and details of any associatedtransactions such as date, amount, goods and so on. The module firstchecks to determine if the certificate is obviously invalid, and thatthe message has been correctly signed by it. The certificate isobviously invalid, for example, if its expiry date has passed, or if itcontains an invalid ‘thumbprint’. Such a thumbprint may be a checksumfor the certificate itself for example. The message has not beencorrectly signed if the signature cannot be verified from theinformation contained within the certificate. Details of certificatevalidation and message signing are more fully described in the ITU andRFC documents previously referenced. The module then makes a check todetermine whether or not the certificate has already been stored in thedatabase and only records those that have not. Where a copy of thecertificate is already stored, the module checks the database record todetermine whether it has been previously identified as revoked in whichcase the transmission is immediately rejected. Otherwise, the modulethen determines, in accordance with policy defining business rules,whether or not to validate the certificate. Taking in to account theresults of any such validation, it then determines whether thecertificate should be relied upon, and therefore whether or not thetransmission signed by the digital certificate should be rejected oraccepted. The module is initiated at step S190, following receipt ofdata containing a digital certificate. Digital certificates aretypically transmitted as attachments to messages and may be identifiedby examining the first few bytes in the header of the attachment. Thesebytes identify the type of file attached and so will indicate whether anattachment is a digital certificate or not.

[0144] The initialisation step S190 occurs after point A in FIG. 3 ifthe module is implemented in a web browser, and after point A in FIG. 5if the module is implemented in an e-mail client. Followinginitialisation, the module proceeds to step S191 in which the expirydate of the certificate is checked, and the digital signature confirmedas having signed the message. If the certificate has expired, or themessage is incorrectly signed, the module proceeds to step S198 andrejects the transmission. Otherwise the module proceeds to step S192 inwhich the database is searched for a previously received copy of thedigital certificate. Control then passes to decision step S194. If acopy of the certificate has been found in the database then controlpasses to decision step S196 where the module determines whether thecertificate has previously been marked as revoked. This will haveoccurred if a previous validity check revealed that a digitalcertificate has been revoked. If the certificate is not already in thedatabase control passes from step S194 to step S202 where the newcertificate and the date on which it was received are stored in thedatabase, together with additional details such as the address fromwhich it was sent and details of any transaction associated with thetransmission such as monetary value, account number etc. If thecertificate has already been marked as revoked in step S196 then controlpasses directly to step S198 in which the transmission comprising thedigital certificate is automatically rejected. This may involve forexample, transmitting an automatically generated message to theinitiator of the transmission whose certificate has been found invalidto explain the refusal, and preventing the recipient of the digitalcertificate from taking any further steps in connection with the refusedtransmission. The module then exits at step S200.

[0145] If, however, the certificate has not been previously marked asrevoked in step S196, then control passes to step S204 in which thehistory of transmissions signed by the certificate, by othercertificates from the same company, or used to conduct transactions onthe same account are considered with policy data to determine if anon-line validity check of the certificate is required. Control alsopasses to step S204 after a new digital certificate has been added tothe database in step S202.

[0146] The policy data contains instructions which when considered inconjunction with the history of signed transmissions previously receivedand revocation checks previously made indicate whether or not thecertificate used to sign a transmission should be verified on thisoccasion. Example policy data is illustrated in FIG. 10 to whichreference should now be made.

[0147] The policy data is stored on the AcceptanceConfidenceRatingbranch on the DigitalCertificates branch of the policy datarepresentation. The AcceptanceConfidenceRating branch sub-divides intotwo separate branches which deal individually with ‘monetary’ digitalcertificates, where a certificate has been used to sign a transmissioninvolving a transaction with the recipient for an amount of money, and“identity” digital certificates which do not involve a monetarytransaction with the recipient of the transmission. Certain certificatesare issued only for use in conjunction with monetary transactions. Forexample, the ‘warranty certificate’ issued by some on-line bankingorganisations, such as Identrus, as a warranty to the receiver of thesigned transmission. Such warranty certificates testify that the senderof the transmission is a customer of an Identrus member bank, and thatif he or she does not make payment, the bank will accept liability.

[0148] Organisations which issue different kinds or classes of digitalcertificate mark each certificate according to its class. Identifying acertificate as being of a particular class is then a matter of knowinghow different organisations classify their certificates and searchingfor the appropriate indicator in the certificate received.

[0149] Issuers of digital certificates may provide many differentclasses of certificate suited for different purposes. These may beseparately dealt with by the policy data by corresponding sub-branchesof the policy datatree.

[0150] In the example policy the first branch entitled“IdentityCertificates” deals with transmissions that do not involve amonetary transaction. The branch comprises four separate sub-branches.The first of these, entitled “AlwaysAcceptFrom” contains a reference toa table, ‘table a’, which lists the names of individuals andorganisations who are considered to be reliable. The names listed inthis table will be those known and implicitly trusted by the company,for whom, it is not considered necessary to determine whether or not adigital certificate has been revoked by its issuer.

[0151] The second branch entitled “AlwaysCheckFrom” contains a referenceto a separate table, table b, in which the names of organisations andindividuals for whom digital certificates should always be checked arestored. Clearly, the contents of table a and table b will depend uponthe experience of the user of the preferred system and will be left upto that user to enter.

[0152] The third branch entitled “CheckIfDaysSinceCertificateReceivedFromCompany” specifies a period of time following the receipt of a validdigital certificate from a company, within which checks of any furtherdigital certificates received from that company are not considerednecessary. In this case, the period of time is set to be 10 days.

[0153] The fourth branch entitled “CheckIfDaysSinceLastReceivedThisCertificate” specifies a similar time period in the case of anindividual digital certificate. In the example shown the policy dataspecifies that validation checks on any given digital certificate needonly be made every 30 days. Again, the number of days specified on bothof these branches is left to the user of the preferred system to decide.The amount of time that has passed since a valid digital certificate hasbeen received may be determined by referring to digital certificates andassociated data stored in the database. By checking digital certificatesperiodically, rather than each time they are received allows money spenton making checks to be saved. The MonetaryCertificates branch alsocontains an AlwaysAcceptFrom and an AlwaysCheckFrom branch which referto tables x and y respectively. Table x lists all those organisationsand individuals for whom no status check of a digital certificate isrequired; table y lists all those for whom a check is always required.The MonetaryCertificate branch also contains a CheckIfAmountExceedsbranch which specifies a threshold transaction amount over which alldigital certificates must be checked and lastly an IfRecentlyCheckedbranch which sets out two conditions for performing checks on a digitalcertificate that has been recently received and validated. TheIfRecentlyChecked branch allows the user to specify that digitalcertificates received for transactions for a small amount, in this case$5000, received within a specified time, in this case 30 days, of aprevious revocation check, need not be validated.

[0154]FIG. 11 illustrates the plug-in module process which interactswith the policy data shown in FIG. 9. This process is a sub-process ofthat shown in FIG. 8 and occurs at step S204 resulting in decision stepS206 in which the plug-in module determines whether or not to perform anon-line check of the status of the Digital Certificate it has received.The sub-process begins in step S220 from which control passes todecision step S222 in which it is determined if the transmission ismonetary from the class of the Digital Certificate used to sign themessage. If the transmission is monetary then control flows to decisionstep S232, which is the first in a chain of decision steps correspondingto the branches in the MonetaryCertificates branch of theAcceptanceConfidenceRating branch of the policy data.

[0155] If in step S222, it is determined that the transmission is notmonetary, control passes to decision step S224, which is the firstdecision step in a chain of decision steps corresponding to theIdentityCertificates branches of the AcceptanceConfidenceRating branchof the policy data. In each of the decision steps in the chain a simplecheck is made to see whether the conditions specified on each sub-branchof the IdentityCertificates branch of the policy data is satisfied.Depending upon the results of that check control flows either to stepS242 in which confidence in the Digital Certificate is established andno on-line check of the Digital Certificate's status is deemednecessary, or step S244 in which confidence is not established and anon-line check is deemed necessary, or to the next decision step in thechain.

[0156] Thus, in decision step S224, in which it is determined whetherthe sender of the Digital Certificate is listed in table a, that is the“AlwaysAcceptFrom” table, if the sender of the Digital Certificate islisted in Table A then control flows from decision step S224 to stepS242 where confidence is established in the Certificate and thesub-process ends returning to step S208 in FIG. 8. If the sender is notlisted in table a then control flows from step S224 to the next decisionstep in the chain step S226 in which it is determined whether the senderof the Digital Certificate is listed in table b, that is the“AlwaysCheckFrom” table. Similarly, if the sender is listed in thistable control flows to step S244 at which an on-line check of theDigital Certificate's status is deemed necessary. Control returns fromstep S244 in the sub-process to step S210 in FIG. 8.

[0157] If the sender of the Digital Certificate is not listed in table bthen control flows from decision step S226 to the next decision step inthe chain which represents the next condition listed as a sub-branchlisted in the policy data. Thus, in decision step S228 a check is madeas to whether this Digital Certificate has been validated in the last 30days. This will involve looking up the Digital Certificate in thedatabase of stored Digital Certificates and extracting from the storedinformation the date on which the Digital Certificate was last checked.If the status of the Digital Certificate has been checked in the last 30days, control flows to step S242 where confidence is established. If theinformation in the database of stored Digital Certificates indicatesthat the Digital Certificate has not been checked in the last 30 daysthen control flows from step S228 to decision step S230 in which a checkis made to see if another Digital Certificate has been received from thesame company and if that Digital Certificate has been checked within thelast 10 days. This determination again involves checking the database ofstored Digital Certificates and information relating to those DigitalCertificates. If the other Digital Certificate has been checked in thelast 10 days then control flows to step S242 where confidence in thereceived Digital Certificate is established. If not, then control flowsto step S244.

[0158] In the case of a monetary transmission, the conditions set out onthe policy data are stepped through in decision steps S232 to decisionstep S240. If in decision step S232 the sender of the DigitalCertificate is found to be listed in table x, which sets out the namesof companies and organisations for which no check of the DigitalCertificate status is deemed necessary, then confidence is establishedand control passes to step S242. Otherwise control passes to the nextdecision step in the chain which is decision step S234. At decision stepS234 if the sender of the Digital Certificate is founded listed in tableb, that is the “AlwaysCheckFrom” Table, then confidence is notestablished and control passes to S244. Otherwise, control passes todecision step S236, where it is determined whether the amount for whichthe transaction is being made exceeds $10,000. This determination ismade with reference to the signed transaction data which will containthe monetary amount either in a manner pre-determined by the issuer ofthe certificate, or contained within the e-mail or associated e-mailsforming the transaction or transmissions. If the transaction is found tobe for an amount to be in excess of $10,000, or if the amount of thetransaction cannot be determined with a reference to the datatransmitted, then confidence is not established and control passes tostep S244. Otherwise, control passes to decision step S238 in which itis determined whether the Digital Certificate has been checked withinthe last 30 days. Again, this determination is made with reference tothe database of stored Digital Certificates and data relating to DigitalCertificates. If the certificate has not been checked within the last 30days then confidence is not established and control passes to step S244.If it has been checked, then control passes to decision step S240 where,if the previously determined amount of the transaction is deemed to beover $5,000 then confidence is not established and control passes tostep S244. If the amount of the transaction is under $5,000 then it isclassed as an acceptable risk to rely on the Digital Certificate,confidence is established and control passes to step S242.

[0159] These last two conditions allow the system to determine whetherto check the certificate's status based on recent trading history. Iffor example, a transaction is about to be made by a party for a modestsum, i.e. under $5000, and the search of the recorded transaction andcertificate details reveals that quite recently, the same party made atransaction and at that time their digital certificate was confirmed asbeing valid, then it is arguable that checking the validity of theparty's certificate again so soon after the first is unnecessary, and itis preferable to trust in the party rather than paying the validationfee a second time.

[0160] It will be appreciated that the instructions in the policy filemay be set out to reflect the level of confidence the company has in itscustomers or suppliers, based on the experience of individuals withinthe company, the amounts of transactions that are deemed allowablewithout significant risk and so on. The policy file may also be set upto implement more general policies which are to be used in conjunctionwith a record of transaction details for the holder of that digitalcertificate. For example, any transaction that is offered by the holdermay be compared against the record of those that he has made before tosee if the amount and the goods and services requested are in keepingwith his trading history. If they are not, then it may be desirable tocheck the validity of the certificate to confirm that it is still validand guarantees the identity of the sender. If it has been revoked, thena third party may have acquired the original holder's private key and beattempting to make fraudulent transactions.

[0161] Having checked the policy data in step S204, confidence in thedigital certificate will either have been established or will not havebeen established. In decision step S206, if confidence has beenestablished then control passes to step S208 in which the transmissioncontaining the transaction is accepted. Control then passes to step S200where the module exits and control passes back to point A in FIG. 3 inthe case of a web browser, or point A in FIG. 5 in the case of an e-mailclient.

[0162] If in step S206 confidence in the digital certificate is notestablished, then control passes to step S210, where an on-linevalidation check is performed on the digital certificate. This mayinvolve checking to see whether the Digital Certificate has been revokedor whether, in the case of an eCommerce transaction, the issuer of theDigital Certificate will confirm a warranty for the amount promised inthe transaction. Control next passes to step S212, in which the validitystatus stored in the database for that certificate is up-dated. Controlthen passes to decision step S214 in which, if the certificate was foundinvalid, control passes to step S198 where the transmission is rejected,or to step S208 where the transmission is accepted. Rejection of thetransmission may mean that it is deleted from the recipients mail boxbefore it has been opened, or that the transmission is marked with theword ‘rejected’ or some other indicator. Following either of steps S198or S208, control passes to step S200 where the module exits. Whenever atransaction is allowed to proceed the database is updated such that itincludes information about the transaction, such as date and amount, inorder that the information may be used in determining the need forfuture validation checks.

Recording of information.

[0163] The preferred system also provides an automatic way in which torecord transaction information for transactions carried out on-line. Inthis context, the word “transaction” and “eCommerce transaction” areintended to mean an agreement promising money or money's worth madebetween two parties over the Internet, or even over the same network ofa company. Normally, the user himself is responsible for maintainingtransaction information by making hard copies of the relevant electronicrecords or by actively storing copies of any electronic records in fileson his computer. The reliance on manual methods to ensure these recordsare maintained is clearly both unreliable and labour intensive.

[0164] The preferred system on the other hand scans the informationcontent of all communications processed by the system for indicationsthat a transaction has begun or is taking place. Such indications arenumerous. The most straightforward is whether the link is secure or notas most web pages negotiate a secure link before a transaction iscarried out and close that link afterwards. Determining whether a linkis secure is achieved by examining the URL of the destination web page.A secure link is indicated by an ‘s’ after the prefix ‘http’. Thus, onemode of operation of the preferred system is to record all datatransmitted to a web page while a link is secure. The preferred systemalso maintains a record of web pages that negotiate secure links butthat are not eCommerce sites, i.e. those that are connected to otherthan to make purchases, and not record any data transmitted to thesepages. Such a web page might be Microsoft's Hotmail web page whichprovides an e-mail service.

[0165] Another indication might be simply the URL of the site. In thiscase the preferred system may be configured to record all datatransmitted to a web page which has been identified as that of anon-line trading company. Other indications might be an identified creditcard number, an electronic receipt, an e-mail acknowledging the sale,use of a digital certificate, in particular a digital warrantycertificate, or a purchase code.

[0166] Once a transaction has been identified as occurring, thepreferred system may record the details of the transaction by bothstoring in entirety each communication between a user and the identifiedtrader, or by scanning the transmissions and extracting particulardetails, such as date, amount, type of goods, quantity and so on.

[0167] Recording of transaction data may be stopped when the end of thetransaction is identified or after a predefined number of transmissionsbetween the purchaser and the trader have taken place. Similarly, once atransaction has been identified, the preferred system may record in thedatabase a predefined number of cached transmissions that took placeimmediately before the first recognised transmission of the transaction.

[0168] This will be useful when, for example, the first indication thata transmission is occurring is the detection of a credit card number oran electronic receipt, since these are likely to received at the veryend of a transaction. The prior transmissions may, for example consistof web pages containing information regarding the goods or servicesbeing purchased, or an exchange of e-mails where specification ordelivery terms were agreed. Note that it is perfectly possible for theprior transmissions to be of the same type as that in which thetransaction was detected, of a different type, or be a mixture of types.For example a user might visit a web site www.abc.com, obtain details ofgoods, and then order them in an email sent to orders@abc.com.

[0169] The preferred system records the transaction details in acentralised common database 42. Additionally, the database may be alocal file or a service on a network. The information stored in thedatabase may be encrypted using known encryption techniques so that onlya person with the necessary authorisation may access it.

[0170]FIG. 12 is an illustration of the operation of an exampleimplementation of a module for identifying when an electronictransaction is being conducted on-line. FIG. 14 illustrates the processby which the preferred system records an identified transaction in thedatabase, and FIG. 15 illustrates how the preferred system allows anidentified transaction to be approved or rejected on the basis of apredetermined approvals policy.

[0171] With reference to FIG. 12, the operation of a module foridentifying when an on-line transaction is occurring will next bedescribed.

[0172] The module begins operation at step S250 in response to receivingdata or in response to a user initiating transmission of data to aremote site. In the case of a web browser implementation this will beafter point A or after point C respectively as shown in FIG. 3; in thecase of implementation in an e-mail client it will be after point A or Brespectively as shown in FIG. 5.

[0173] Control then passes to decision step S252 in which it isdetermined whether, in the case of a web browser, a secure link has beennegotiated between the site transmitting data and the site receivingdata. This may be achieved by querying the URL address that has beenconnected to, as mentioned above, or interrogating the web browser tosee if encryption is being employed. In the case of an e-mail messagethis step is omitted and control passes directly to step S260. Sinceon-line web browser transactions usually involve the transmission ofpersonal information, such name and address, credit card number or otheraccount identifying information, secure links are usually negotiated asa matter of course. Thus the presence of a secure link alone is a goodindication that a transaction is taking place. However, secureconnections may be negotiated for reasons other than the transmission oftransaction details. Thus, if in step S252 it is determined that theconnection is secure, control passes to step S254, in which the addressof the remote site to which the connection has been made is checkedagainst a list of known sites which do not provide facilities forconducting on-line transactions but which do establish secureconnections. Browser based e-mail sites such as Microsoft's Hotmail siteis one such example. Control then passes to decision step S256 where adetermination based on the previous check is made. If the site addressis identified as a non eCommerce site, that is one which does notfacilitate the making of a transaction, then it is determined that atransaction may or may not be occurring and control passes to decisionstep S260 to make further checks on the transmission content. If in stepS256 the site address is not identified as a known non eCommerce site,then it is assumed that an on-line transaction is occurring, and themodule exits at step S258.

[0174] If a secure connection is found not to have been established atstep S252, or if a secure connection has been established but to a knownnon- eCommerce site, as determined at step S256, or the transmission isan e- mail, then control passes to decision step S260. In decision stepS260, the first of a number of checks on the content of the transmissionare made in order to determine whether or not it is part of atransaction. In step S260, the transmission is scanned to see if itcontains a credit card number. The method for doing this has beendescribed with reference to FIG. 8. If a credit card number is found inthe transmission then it is assumed that a transaction must be occurringand control passes to step S258 at which the module exits. If no creditcard number is found then control passes instead to decision step S262where the transmission is scanned to see if it contains an account code.Account codes may be (for example) stored in a separate file which isaccessed by the module when performing this step or alternatively anaccount code may be identified from descriptive data in the transmissionsuch as a field name like “Account Number” or similar charactersappearing in the text of a message.

[0175] If in decision step S262 an account code is found, then it isassumed that the transmission constitutes part of a transaction andcontrol passes to step S258 where the module exits. If no account codeis found then control passes to step S264 where, in the case of a webbrowser, the URL is compared with a list of known eCommerce URLs storedin a file or in a database. In decision step S266, a determination onthat comparison is made. If the URL is found to be at a known eCommercepage, or within a known set of eCommerce pages, then it is determinedthat an eCommerce transaction is taking place and control passes to stepS258 where the module exits. Similarly, in the case of an e-mail, thedestination address may be compared against a list of known eCommercee-mail addresses, for example ‘orders@abc.com’, and if a match is foundthen it is determined that an eCommerce transaction is taking place andcontrol passes to step S258 where the module exits.

[0176] The checks that have been described are only representative ofthe possible checks that could be made to determine whether or not atransmission is likely to be part of an eCommerce transaction and arenot intended to be exhaustive. Furthermore, the order in which thechecks have been illustrated has no special significance. The order issimply dependent on the structure of the policy data as will be seenfrom reference to FIG. 13.

[0177] In step S268, a general check is illustrated which represents anyfurther check for an indication of a transaction, in addition to thosedescribed above, which a company decides it is desirable to employ, suchas searching for purchase codes or embedded codes placed in the data forexample. It is preferred that the web browser or e-mail client beingused in the preferred system allows the user to mark transmissions withan embedded code to indicate that the transmission is part of atransaction and should be recorded. Also, the embedded code could beplaced in the data by the web site or the e-mail client transmittingsome of the transaction data to the user's workstation.

[0178] Control passes to this step after step S266, if the site is notrecognised as a known eCommerce site and if such a transaction indicatoris found in step S268, then a transaction is deemed to be occurring andcontrol passes to step S258 where the module exits. If at step S268, nosuch indicator is found then no transaction is deemed to be occurringand the module exits at step S258. Following exit, the data may betransmitted, following points C and B in FIGS. 3 and 5 respectively, orbe processed following on from its receipt at point A in FIGS. 3 and 5.

[0179] In the example described, the aim is to start recordingtransmissions and possible transaction details if there is just asuspicion that a transaction is occurring. It is assumed that recordingdata which is not part of a transaction is preferable to not recording atransaction at all FIG. 13 is an illustration of the policy data used toidentify that eCommerce transaction is occurring and to control the wayin which the transaction data is recorded. The policy data isrepresented by a Transactions branch of the policy data tree whichsub-divides into two separate sub-branches called “Identification” and“Termination” . The Identification branch is itself divided into fivesub-branches which correspond to the determinations made in the processillustrated in FIG. 12. The first of these sub-branches entitled“IfConnectionGoesSecure” allows a user to specify whether recordingshould start when the plug-in module detects that the connection to theweb server has become secure. The conditions specified on the thissub-branch corresponds to decision step S252 shown in FIG. 12. It willbe appreciated with reference to FIGS. 12 and 13 that the flow ofcontrol shown in FIG. 12 corresponds to the layout of the conditionsspecified on the branches of the policy data tree shown in FIG. 13. TheExcludedSites branch of the IfConnectionGoesSecure branch contains areference to table q in which the web sites known to negotiate securesites but which are known not to be eCommerce web sites are listed.Table q is referred to in step S256 of the process shown in FIG. 12.

[0180] The next sub-branch of the identification branch is entitled“IfCreditCardNumberPresent” and allows the user to specify whether thedetection of a credit card number should or should not be used toinitiate recording of data being transmitted or received. Thissub-branch corresponds to decision step S260. The PreviousPagessub-branch of the IfCreditCardNumberPresent branch lists the number ofweb pages, prior to the web page in which the credit card number wasdetected, which should also be recorded. Since credit card numbers arenormally submitted at the end of the transaction, the provision of thissub-branch enables previous web pages which are likely to contain thedetails and request of the transaction to be retrieved and stored. Theseweb pages are cached continuously by the preferred system so that shoulda transaction be identified they may be retrieved from the cache andstored in the database. This will be explained in more detail withreference to FIG. 14.

[0181] The next sub-branch of the Identification branch tree is entitled“IfAccountsCodePresent” and allows a user to specify whether or not thedetection of an account code in the data being transmitted or receivedis to be taken as an indicator to initiate recording of the data. Theaccounts codes are identified in step S262 shown in FIG. 12 by referenceto table r. The reference to this table is contained in the AccountCodessub-branch of the IfAccountCodePresent branch. Note that this table alsoshows the number of previous pages to record, in a similar manner tothat described above for credit card identification, however in thiscase the number of previous pages to record is stored in table rallowing a different number of pages to be specified for each detectedaccount code.

[0182] The IfKnownECommerceSite branch allows the user to specify a listof URLs corresponding to sites, parts of sites, or even single pages,where eCommerce transactions are known to take place. The current pageURL is matched against entries in this list to determine if atransaction is taking place. The KnownSites sub-branch contains areference to table s in which the URLs of known eCommerce sites arestored. The determination of whether the URL of the web site is a knowneCommerce site is made in decision step S266 following step S264 of FIG.12.Lastly, the IfOtherIndicatorPresent branch provides a way for theuser to specify whether or not the determination of other indicatorsshould be used as a starting point for the recording of data. Twosub-branches of this branch entitled KeyWords and PreviousPages specifypossible indicators that may be detected, in this case key words listedin table t, and also the number of previous pages that are required tobe stored if key words are detected.

[0183] The Termination branch of the Transactions branch divides intofour sub-branches which specify conditions which are used to end therecording of data being transmitted or received. Each sub-branch setsout a condition by which the end of the transaction may be defined. Thefirst branch entitled “IfConnectionGoesInsecure” allows a user tospecify that the relinquishing of a secure connection by the web browserindicates the end of a transaction so that recording should be stopped.The other sub-branches specify that when the web site changes recordingshould stop, if a digital receipt is received recording should stop andrecording should stop after the receipt of 20 web pages followingidentification that a transaction is occurring.

[0184] It must be stressed that policy data shown in this diagram, inparticular, but also in the other diagrams is unique to each user. Notonly may a user specify whether or not particular conditions are to beacted on by setting the Yes or No variable accordingly, or by changingthe number of pages that are to be recorded for example, but also thestructure and arrangement of branches and conditions specified on thosebranches may be different from user to user. It will be appreciated thatwhile the example policy describes recording of transactions in a webbrowser environment, a similar policy would control the e-mailenvironment, omitting the secure connection option, but allowing policyto be defined for recording e-mails on detection of credit card numbers,account codes or other identifiable information within them, or wheree-mails are sent to known eCommerce addresses.

[0185] The full benefit of the method for identifying a transaction isrealised when the method is utilised along with means for recordingtransmissions between a user of the preferred system and a remote site.This allows a record of all transactions carried out by a user to bekept and maintained automatically. The records may be kept up to datewithout the need for making paper copies of each transmission receivedor sent. Thus, a company's record keeping is made considerably easierand more accurate.

[0186]FIG. 14 illustrates the operation of a module for recordingtransmissions which comprise a transaction. The module is initiated atstep S270.

[0187] If the module is implemented as part of a web browser, step S270is initiated at point A in FIG. 3 after the receipt of data or afterpoint C in FIG. 3 directly before transmission data to remote site. Ifthe module is implemented as part of an e-mail client step S270 occursafter point A in FIG. 5 after an e-mail has been received or after pointB in FIG. 5 just before an e-mail composed by the user is sent to arecipient. Following step S270 , control passes to step S272, in whichthe test for identifying a transaction, described above with referenceto FIG. 9, is performed and a determination is made as to whether aneCommerce transaction is occurring or not. Control then passes todecision step S274 where, if it is determined that no transaction isoccurring control passes directly to step S276 where the module exits.

[0188] If a transaction is determined to be occurring however controlpasses to step S278 in which the policy is consulted against one or moreof the means of detection, the identity of the sender, the amount of thetransaction, or other parameters to determine which prior transmissions,if any, should be stored with the identified transmission, and in howmuch detail the transmission should be recorded. The policy might, forexample, require that a transaction involving a large sum of money berecorded in more detail than a transaction for a small sum. An exampleof this in operation might be the recording of every web page accessedduring the making of a transaction on an on-line trader's web site fortransactions involving large sums of money, but only recording thetransmission containing an electronic receipt for transactions forsmaller amounts.

[0189] As well as determining the amount of data to be stored, thepolicy file may also determine the nature of the data to be recorded.The entire transmission or web page may be recorded as a series of snapshots of the transaction, in the same way as web pages are stored incache memories for example, or alternatively, individual items of data,such as the date, the trader's identity, the amount and so on, may beextracted from the transmission or web page, and stored either on theirown or together with the snap shot data.

[0190] In this way, memory for storage can be used most effectively toensure that the most important transactions have sufficient space to berecorded. The amount of transaction data to be recorded may also dependon the trader's identity, geographical location, trading history withthe user's company, and the goods and services on offer.

[0191] In FIG. 13, the example policy data shows a simple scenario inwhich the amount of data to record is specified in terms of the numberof web pages that are to be retrieved from the pages cached in memory.The number differs depending on whether a credit card number, an accountcode or a keyword is identified. Furthermore, table r shows that withthe recognition of different account codes the number of previous webpages to store might be different, reflecting the relative importance ofthe account.

[0192] Extending this simple case to a more sophisticated one may beachieved by providing a higher level of detail in the policy data.Additional branches to the policy data tree could specify company orindividual names, or specific keywords relating to goods and/orservices; the amount of data to record depending on these keywords andnames as well.

[0193] Also, the tables might be expanded to refer to the amount ofdifferent types of data that should be stored. Data such as the companyname, what was being sold, the quantity and so on could be extractedfrom e-mail text, from the HTML text defining the web page, or from theDOM representation of the web page and stored in the database.

[0194] All web pages or information stored in the cache may beretrieved, or alternatively the system may retrieve only pages that havedetails in common with the page initially identified as being part of atransaction.

[0195] Alternatively, a list of all stored messages may be presented tothe user for the user to manually select those transmissions whichrelate to the identified transaction.

[0196] Following determination of how much data to record control passedto decision step S280. In step S280 if earlier transmissions, are to bestored, control passes to step S282 where the transmissions stored inthe local cache are retrieved. In the case of a web browser, this may bea determined number of prior pages, as described above. Where thetransaction was detected in a web browser, policy may also dictate thatthe cache is searched for prior e-mail messages relating to thetransaction, for example sent to or received from the same organisation.This may be determined by matching portions of the browser URL toportions of the e-mail addresses. Similarly, transactions detected ine-mail messages may cause both prior e-mails and prior web pages to beretrieved from the cache. Control then passes to step S284 in which theidentified transaction and any retrieved prior transmissions are storedin the system database 42.

[0197] In step S280, if earlier transmissions are not required, controlpasses directly to step S284 where the transmission identified as atransaction is recorded in the system database. At the same time as thetransmissions are stored in step S284, related data such as the useridentity, the amount and the other party to the transaction may also berecorded in the system database to form a complete record, although thiswill depend on the instructions of the policy data. Control then passesto S286 and the module exits.

[0198] Following on from step S276 after the module exits, the data maybe transmitted, following point A in FIGS. 3 and 5, or be processedfollowing on from being received at points C and B in FIGS. 3 and 5respectively.

[0199] Once a transmission has been identified as taking place alltransmission between the user and the other party may be recorded untilthe system detects that the transaction has been completed. Detectingthe end point of a transaction and stopping recording may be done in amanner similar to that described above for identifying whether atransaction is taking place. The most simple implementation is to recordtransmission information until an electronic receipt or shipping orderis received. Alternatively, recording of transmissions may caused tostop after a pre-determined number of transmissions between the user andthe other party have occurred, or if a certain amount of time has passedsince the transaction was identified.

[0200] Transmissions may be made simpler if each time the user changesweb site the cache is emptied. This keeps the memory required for thecache memory low, as well as reducing the number of previoustransmissions that need to be searched if searching techniques are to beemployed.

[0201] It will be appreciated that the methods described above can alsobe used to record associated transmissions which occur after atransaction has been detected and recorded. For example, a transactionmade using a web browser will typically be followed by a confirmatorye-mail sent from the seller to the buyer. This e-mail can be detected asforming part of the transaction, since it will contain commoncharacteristics, such as order number, account number, goodsdescription, price etc. It may also be sent from an address similar tothe web site address, for example ‘customerservices@abc.com’ when theoriginal web site used to make the purchase was ‘abc.com’. A timeelement is preferably used such that only subsequent transmissions whichoccur within a given time period are considered as being associated withthe original transaction.

[0202] The preferred system also provides means for monitoringtransactions that are being made and automatically referring thetransaction for approval if that is deemed necessary. This processallows a large company to monitor and control the transactions beingmade by its employees using a single set of criteria set out in thepolicy data. The policy data may be referred to each time a transactionis identified in order to determine whether the user is authorised tomake that transaction himself or whether he needs to requestauthorisation from higher up in the company. The process is illustratedin FIG. 15 to which reference should now be made.

[0203] The module embodying this process is initiated at step S290. Thisinitiation preferably takes place as soon as all relevant details of thetransaction which need to be considered have been determined, and beforethe transaction is committed. In the case of an e-mail transaction,details such as goods and price are typically contained within a singlee-mail and can be considered prior to transmission of that e-mail. Inthe case of a web browser transaction, the existence of transaction maybe detected before all details are known, in which case initiation doesnot take place until they are. This does not normally present a problemas final commitment does not occur until the very end of the transactionprocess, well after all relevant details are known. Detection of thetransaction and relevant details may be determined in the mannerdescribed above with reference to FIG. 12. Referring briefly to FIGS. 3and 5, it will be seen that step S290 occurs after point C in FIG. 3 inthe case of web browser implementation, or after point A in FIG. 5 inthe case of e-mail client implementation once the required details areknown.

[0204] Control passes from step S290 to decision step S292 in which thedetails of the transaction are compared against the policy settings todetermine whether or not approval is required. The determination may bebased on the identity or the position of the employee making thetransaction, the amount of the transaction, or the other party in thetransaction. In some instances, approval might always be required, suchas if the financial director of a company wishes to review eachtransaction before it is made.

[0205]FIG. 16 is an illustration of example policy data that may be usedto determine whether or not a transaction requires approval from a thirdparty and also to determine the identity of an appropriate approver whois to be used. In this case, conditions in the policy data stipulatewhether approval is required depending on the transaction amount, andthe URL address of the other party to the transaction.

[0206] The relevant policy data is set out on the Transactions Approvalbranch of the policy data tree. This branch sub-divides into foursub-branches. The first branch is entitled“MaximumUnapprovedTransactionAmount” and defines a threshold amount fortransactions. Transactions for amounts over the threshold must beapproved by an approver before they are made.

[0207] The second sub-branch entitled “MaximumUnapprovedMonthlyAmount”defines a maximum amount for transactions that a user may make within amonth. In this case, any transaction made by the user which would causethe monthly total to exceed $2,500 will require approval from a thirdparty, as will further transactions made after that threshold has beenreached.

[0208] The third branch entitled “ExcludedSites” refers to a tablecontaining web site and e-mail addresses of all sites which alwaysrequire approval from a third party before a transaction may be made.Finally, the last branch entitled “Approvers” refers to a table in whichthe names of possible third party approvers are listed. Along side eachname is the maximum transaction amount for which that approver has theauthority to approve, and a list of excluded sites for which thatapprover may not approve a transaction. In the simplest of cases,approvers will be other computer users logged in on the same network asthe user making the transaction such as department managers, orsupervisors. The approvers will, by nature of their role, be members ofthe trading company who assume and who have the authority to assumeresponsibility for the financial transactions the company makes. It isalso possible that approvers might be drawn from a group of people whoare employed primarily for this role, such as people in the financialdepartment only.

[0209] If the conditions on the first three sub-branches of thetransaction branch indicate that approval is required an appropriateapprover may be found by scanning through the table of approvers untilan approver whose transaction limit is equal to or greater than of theproposed transaction and who is not prohibited from approvingtransactions to the relevant site is found.

[0210] It will be appreciated that the example policy data shown in FIG.16 is policy data that is specific to a single computer user, or groupof users, in the network. Other users, or groups, may have differentsettings and a different list of approvers.

[0211] It will be appreciated that the conditions to determine anappropriate approver may be introduced by creating new sub-branches ofthe policy data tree.

[0212] The operation of the approvals process could for example beextended to any kind of transmission, not just those comprising aneCommerce transaction. Such operation may be implemented by having theconditions defined or the sub-branches of the policy data specifyusernames, addresses or keywords for example that are to be identifiedin the transmission and acted upon. Thus, all e-mail transmissions to aparticular company or individual may be caused to require approval, orall e-mails containing predetermined information recognised via keywordidentification.

[0213] If it is determined in step S292 that no approval is required,control passes directly to step S294 at which the module exits.Following step S294 the transmission of the transaction is permitted andthe transaction may be proceed. Control returns from step S294 to pointC in FIG. 3 or to point B in FIG. 5.

[0214] However, if in step S292, after consulting the policy settings,it is determined that approval of the transaction is required, controlpasses to step S296 in which the particulars of the transaction are usedto determine an appropriate approver for the transaction. The approvermay be a company employee logged on at his workstation, or at aworkstation with a dedicated approver function such as Operator consoles44, as shown in FIG. 2, or may even be an automated process. In the caseof a large company with a number of departments, it maybe advantageousto have a group of approvers for each department, each group monitoringthe department's accounts. This allows transactions to be rejectedbefore they are made if, for example if the department head decides thathe wishes to temporarily suspend purchases, or purchases of a particularnature.

[0215] Control passes from step S296 following determination of anappropriate approver to step S298 where an approval request istransmitted to the designated approver via systems approval queue 100.Following step S298 control passes to decision step S300 where it isdetermined if a response from the approver has been received. A timer isstarted the moment a request for approval is submitted. If a responsehas not been received in step S300 control passes to step S302 where itis determined from the timer whether or not a time out period haselapsed. Providing the period has not elapsed, control passes from stepS302 back to S300 where the system continues to wait for a response fromthe approver. Thus decision steps S300 and S302 form a loop in which thesystem waits until a response is received or until time out expires. Indecision step S300 once a response is received, control passes to stepS304 in which action is taken depending upon whether the transaction wasapproved or rejected.

[0216] If the transaction was approved control passes from step S304 tostep S294 at which the module exits and the transmission is allowed toproceed. If however the transmission is not approved then control passesfrom step S300 to step S306 at which the module exits. Exiting at stepS306 however prevents the transmission of the transaction from takingplace and returns the user to point A in FIG. 3 in the case of webbrowser implementation or to step S132 “compose e-mail” in FIG. 5 in thecase of e-mail client implementation.

[0217] Also, if in step S302 the ‘time-out’ is deemed to have expiredwithout a response from the approver having been received then controlpasses directly to step S306 at which the module exits.

[0218] The right hand side of FIG. 15 shows the steps involved for theapprover. The approval process is initiated in step S310, from whichcontrol passes to step S312 in which the approver's machine queries thesystems approval queue for any new approval requests. Control thenpasses to decision step S314. In step S314 if no request is pendingcontrol passes back to step S312 where the system queue is polled onceagain. These steps are repeated until an approval request is received oruntil the approver deactivates the approval process.

[0219] In step S314 if an approval request is received, control passesto step S316 in which the approval request is downloaded from thesystems queue and the approver himself decides whether to approve therequest or refuse it. Control then passes to step S318 in which theapprover's response is transmitted back to the system approvals queueand from there back to the users work station.

[0220] Control passes from step S318 back to step S312 in which thesystem approvals queue is queried for new approval requests. It will beappreciated that the approvals process could be entirely automated insome circumstances. For example, transactions may be automaticallyrejected if the company does not have sufficient funds, if they wouldcause budget amounts to be exceeded, or if they are simply over amaximum amount. Such automation could alternatively be provided as partof the user process, such that an approvals request is not even made.

Security

[0221] The preferred system provides means to assign an appropriatesecurity rating to the transmission in dependence on the identifiednature of the data being transmitted. The security rating assigned maybe set by the user of the system using the policy data to reflect hisneeds.

[0222] The simplest implementation of the policy data in this case is alist containing in a first column possible types of data, such asemployee passwords, employer passwords, credit card numbers, bankingdetails and so on, and containing in a second column, the desiredencryption strength (in key bits for example) deemed appropriate foreach data type. It will be appreciated that other ways of assigningsecurity levels in dependence on the determined nature of the data mayalso be employed within the scope of the invention.

[0223]FIG. 17 shows an example illustration of policy data definingappropriate encryption strengths for various types of data. The policydata takes the form of a number of key-value pairs arranged on separatebranches of the policy data tree. The key specifies the type of datathat is being transmitted such as passwords, credit card numbers,submitted key words and a general key for any other submitted data. Thevalues that correspond to these keys are the encryption strength in bitsthat is deemed appropriate for the transmission of the data specified inthe key. The key value pairs are arranged on several branches of theRequiredEncryptionLevel branch of the TransmittedDataSecurity branch ofthe policy data tree. Thus, in the example, it may be seen thatpasswords have a desired encryption strength of 40 bits, company creditcard numbers and personal credit card numbers both have a desiredencryption strength of 128 bits, submitted key words have a desiredencryption strength of 40 bits and other submitted data requires noencryption.

[0224] The SubmittedKeywords branch refers to particular words orstrings or text that have been designated as sensitive and requiringsome form of encryption. These may be usernames, address information,financial information or pre-selected words such as “confidential” or“secret”. The submitted keywords may be detected by referring to a tableor file in which they are stored.

[0225] Furthermore, each branch of the policy data may, instead ofgiving a general encryption strength, refer to a table in whichdifferent passwords or credit card numbers, for example, are listedalong with corresponding encryption strengths specific to each passwordor number.

[0226] Once a security rating has been assigned, the plug-in moduleinterrogates either the web browser to determine the security of thelink that has been established by the web browser with the web serverfor transmission of that information, or in the case of an e-mailtransmission, the encryption settings that the user or application havedetermined will be applied to the message. Typically, this will be thecryptographic strength of the encryption algorithm used to encode thedata for transmission. Such transmission details are received by the webbrowser as part of the ‘electronic handshake’ from the web serviceprovider.

[0227] A secure link is usually indicated in a Browser window by thepresence of a closed padlock icon in the bottom right corner. A user canclick on the icon to interrogate the level of security that has beenprovided by the handshake. In doing so they may receive a notificationof the form “SSL secured. (128 bit)”. The first part of the notificationdescribes the type of the encryption used while the second partdescribes the encryption strength. The plug-in module is implemented toautomatically obtain this data from the browser so that it may be usedto determine whether or not the security level is adequate for aproposed transmission. Similarly, in the case of an e-mail message, theplug-in module determines the encryption settings that the user orapplication has specified are to be used prior to transmission of themessage.

[0228] The module compares the specified encryption strength with thatof the link or message and depending on the result of the comparisonperforms one of the following actions:

[0229] a) If the security of the link is appropriate for the nature ofthe information being transmitted, the module allows the information tobe transmitted;

[0230] b) If the security of the link is more than that required for thetransmission of the information then, the module may either allow theinformation to be transmitted at that level of security, automaticallyrenegotiate with the web server and the web browser a new appropriatelevel of security and transmit the information at that level, or promptthe user that the present level of security is unnecessary and invitethem to take action.

[0231] c) If the security of the link is not sufficient for the natureof the information being transmitted then, the module may either preventthe transmission from taking place and warn the user, automaticallyrenegotiate with the web server and the web browser a new appropriatelevel of security and then transmit the information at that level, or inthe case of an e-mail automatically increase the encryption strengthsetting, or prompt the user that the present level of security is notsufficient and invite them to confirm that they still wish fortransmission to take place.

[0232] It will be appreciated that the plug-in module could beconfigured to respond to a difference in the determined desirable levelof security and that being provided in a number of ways and that theactions outlined above are only illustrative.

[0233] Further actions that may be taken by the system might includerequesting a different web page to be down loaded to the user's machineor modifying the submitted field data such that sensitive information isnot transmitted.

[0234] The operation of a browser or e-mail plug in module formonitoring the data being transmitted by a user of the preferred systemis illustrated in FIG. 18, to which reference should be made. The modulebegins operation at step S320 at point C in FIG. 3, just prior to thetransmission of the data to a web server or at point B in FIG. 5 justprior to transmission of an e-mail. Control then passes to step S322, inwhich the module parses the data about to be transmitted and searchesfor credit card numbers. A possible method for doing this was describedearlier with reference to FIG. 8. If no credit card number is detectedin the data then control passes to step S314 in which the modulesearches for passwords in the data about to be transmitted. A method fordoing this has been described above, with reference to FIG. 6. If nopassword is found in the data, then control passes to step S316 in whichthe module searches for company account or purchase codes in the data.Recognising account or purchase codes may be achieved by storing thecodes of the company in a file and attempting to match these codes withany strings of digits found in the outgoing data. If no account code isfound then control passes to step S318, where the module searches forindications of other sensitive data in the data to be transmitted. Suchindications will need to be defined in advance preferably in a separatefile used for detection, and will be dependent on the requirements ofthe users of the preferred system. Examples might be specified keywordsrelating to projects the company is undertaking, project titlesthemselves, personal details address of the recipient of the data, or ofthe sender, or even the word ‘confidential’ or ‘private’ included in thedata itself.

[0235] If no such indications are found that the data is sensitive andrequires stronger protection before it is transmitted, then thetransmission is allowed to proceed at the current level of encryption.This may mean that transmission takes place without any encryption beingapplied.

[0236] If however any of the checks in steps S322 to S328 reveal datathat is deemed sensitive then control passes to step S332 in which asecurity rating is assigned to the detected data. This is achieved bycomparing the detected data with pre-determined entries in the policydata.

[0237] Each entry on the branch of the policy data has a pre-assignedlevel of encryption which is the minimum level that may be used fortransmission of that data. The entries in the table and the assignedlevel of encryption, as with all the policy settings, are decided by thecompany using the preferred system in dependence on their requirements.Assigning a security rating is then simply a matter of looking uppassword, credit card number or other data in the policy data andreading off the corresponding rating. References to tables on a subbranch of the policy data may be used to allocate different encryptionstrengths to different passwords, credit card numbers and so on.

[0238] Once the appropriate security level has been determined in stepS332, control passes to step S334 in which the module determines thelevel of encryption that has been negotiated with the web server towhich the data is being transmitted, or is to be used by the e-mailapplication prior to transmitting the message. This may be achieved byinterrogating the web browser or e-mail application, or by settingencryption strength variables at the time the link is established ore-mail encryption requirements determined, both of which will occurprior to transmission.

[0239] Control then passes to decision step S336 in which the desiredlevel of security, i.e. the encryption strength, is compared with thatdetermined in the previous step. If the desired level of encryption islower than or equal to that determined in step S334, then there isdeemed to be enough protection for the data to be transmitted andcontrol passes to end step S330, where the module exits. Following stepS330, control returns to either point C in FIG. 3 or point B in FIG. 5depending on whether the module is implemented in a web browser or ane-mail client. Transmission of the data may then proceed in the usualway.

[0240] If however in step S336, the desired level of encryption isgreater than that currently set, then the module does not allowtransmission to go ahead until the proper level of encryption has beennegotiated. Control passes to decision step S338 in which the moduledetermines if it is able to increase the encryption strength, and if sopasses control to step S340 where a new stronger encrypted link isnegotiated, or in the case of an e-mail a higher encryption strengthset.

[0241] The highest level of encryption that is available depends on thesoftware being used by both the web server and the web browser, or inthe case of an e-mail by the sending and receiving e-mail applications.There may then be cases in which the appropriate level of encryption isnot available by one party and transmission of the data is never allowedto proceed. Furthermore, certain types of data may be given a securityrating that indicates that no level of encryption will ever be highenough to protect it, ie: preventing that data from ever beingtransmitted.

[0242] Having attempted to re-established the link, or changed thee-mail encryption settings, to a higher encryption strength, controlpasses back to step S334 to ensure the link or settings are now at asuitable strength. If the appropriate encryption level cannot berenegotiated in step S338 or an attempt to increase the encryptionstrength at step S340 has not been successful, then it is deemed unsafeto transmit the data, and control passes to end step S342 where themodule exits. Following exit at step S342, control returns to point A inFIG. 3, or to step S132 in FIG. 5 ‘compose e-mail’, for the user toreconsider and edit or abort the transmission. A suitable message mayalso be displayed to the user explaining the reasons for thetransmission being prevented.

[0243] The preferred system therefore provides a way of ensuring thattransmission of data is as secure as possible. It precludes thepossibility of a user forgetting to secure a transmission, andnegotiates a more appropriate level of security if that being used isnot sufficient.

[0244] Web Browsers may provide similar facilities to warn the user thatuser entered data is about to be sent over an insecure link or providefacilities to encrypt all messages by default. The preferred systemhowever provides the ability to examine the content of data to betransmitted to determine its security requirement, to allow or preventtransmission based on such security requirements, and on the determinedsecurity level of the link (encryption strength). It will be appreciatedthat the preferred system provides a significantly improved system forsecure transmission which reduces the possibility of human error.

[0245] Although the implementation of the preferred system has beendescribed with reference to plug-in modules for existing applications,the invention may be implemented by providing web browsers or e-mailclients in which the functionality of the plug-in modules described hereis already coded from the outset.

What is claimed is:
 1. An information management system comprising: aplurality of workstations adapted for connection to a computer network,each workstation having a memory; a data repository arranged to receivedata from each of said workstations; an application stored in saidmemory of each workstation for transmitting outbound data to saidnetwork and receiving inbound data from said network; policy datacontaining rules defining relevant data which is to be stored in saiddata repository; and an analyser, said analyser being operable inconjunction with said policy data to monitor at least one of saidoutbound data and said inbound data, to identify in at least one of saidoutbound data and said inbound data, relevant data that is to be storedin said data repository in accordance with said rules in said policydata, and to cause said relevant data to be stored in said datarepository.
 2. The system of claim 1 wherein said relevant data that isto be stored in said data repository is encrypted prior to it beingtransmitted to said data repository.
 3. The system of claim 1 whereinsaid relevant data that is stored in said data repository is encrypted.4. The system of claim 1 wherein said computer network, to which saidone or more workstations are adapted for connection, is the Internet. 5.The system of claim 4 wherein said analyser is operable to identify, asrelevant data, at least one of usernames and passwords used to identifya user, and usernames and passwords used to access web pages on theInternet, and the URL address of the web page at which those usernamesand passwords are used, said identified usernames, passwords and saididentified URLs being stored in said data repository.
 6. The system ofclaim 5 wherein said analyser is operable to identify usernames andpasswords from the field names of data contained in at least one of saidoutbound data and said inbound data.
 7. The system of claim 5 wherein arepresentation of the input fields of a web page is stored in saidmemory of said one or more workstations, and wherein said analyser isoperable to identify usernames and passwords from said representation.8. The system of claim 5 wherein said analyser is operable to identifyusernames or passwords from the field types of data contained in saidoutbound or said inbound data.
 9. The system of claim 4 wherein saidanalyser is operable to identify, as relevant data, digital certificatescontained in at least one of said outbound or said inbound data or usedto digitally sign signed data in said inbound data or said outbounddata, or sufficient descriptive data to identify such digitalcertificates, said digital certificates and/or said descriptive databeing stored in said data repository.
 10. The system of claim 9 whereinsaid analyser is operable to identify one or more of the following dataas relevant data: whether or not said digital certificate has beenrevoked; the identity of the holder of said digital certificate; theamount of any eCommerce transaction being made that is related to saiddigital certificate; the goods or services being sold in any eCommercetransaction being made with said digital certificate; the date ofreceipt of said digital certificate; and wherein said identified data isstored with said digital certificate in said data repository.
 11. Thesystem of claim 4 wherein the analyser is operable to identify when aneCommerce transaction is occurring and if an eCommerce transaction isidentified as occurring, to identify in said outbound or said inbounddata one or more of the following data as relevant data: the URL addressor e-mail address of the remote location to which outbound data is beingtransmitted or inbound data is being received; the web pages accessed bya user of said one or more workstations during the transaction; theamount of the transaction; the goods or services being traded in thetransaction; the date of the transaction; and wherein said relevant datais stored in said data repository.
 12. The system of claim 1 whereinsaid analyser is located on each of said one or more workstations. 13.The system of claim 1 wherein said application is a web browser.
 14. Thesystem of claim 13 wherein said analyser is a plug-in module of said webbrowser.
 15. The system of claim 14 wherein said web browser isMicrosoft's Internet Explorer and said analyser is a Browser HelperObject.
 16. The system of claim 1 wherein said application is an e-mailclient.
 17. The system of claim 16 wherein said analyser is a plug-inmodule of said e-mail client.
 18. The system of claim 17 wherein saide-mail client is Microsoft's Outlook e-mail client and said analyser isa Microsoft Exchange client extension.
 19. The system of claim 1 whereinsaid network includes a server and said analyser is located at a pointon said network intermediate said one or more workstations and saidserver, or said analyser is located at said server.
 20. The system ofclaim 1 further comprising a supervisor workstation, said supervisorworkstation having access to said data repository and being operable toview said relevant data stored in said data repository.
 21. The systemof claim 20 wherein said policy data is accessible by said supervisorworkstation, such that a user of said supervisor workstation can editsaid policy data.
 22. The system of claim 1 wherein a workstation ofsaid plurality of workstations has access to said data repository and isoperable to view said relevant data stored in said data repository. 23.The system of claim 1 wherein said computer network to which said one ormore workstations are adapted for connection is a public computernetwork, and wherein said one or more workstations together form aprivate computer network.
 24. A method of managing informationcomprising the steps of: providing a plurality of workstations adaptedfor connection to a computer network, each workstation having a memory;providing a data repository arranged to receive data from each of saidworkstations; providing an application stored in said memory of eachworkstation for transmitting outbound data to said network and receivinginbound data from said network; providing policy data containing rulesdefining relevant data which is to be stored in said data repository;and analysing at least one of said outbound data and said inbound data,with reference to said policy data, to identify in at least one of saidoutbound data and said inbound data, relevant data that is to be storedin said data repository in accordance with said rules in said policydata; and storing said relevant data in said data repository.
 25. Themethod of claim 24 further comprising the step of encrypting saidrelevant data that is to be stored in said data repository prior to itbeing stored in said data repository.
 26. The method of claim 24 furthercomprising the step of encrypting said relevant data that is stored insaid data repository after it has been stored in said data repository.27. The method of claim 24 wherein said computer network, to which saidone or more workstations are adapted for connection, is the Internet.28. The method of claim 27 wherein in the analysing step, at least oneof usernames and passwords used to identify a user, and usernames andpasswords used access web pages on the Internet, and the URL address ofthose web pages, are identified as relevant data.
 29. The method ofclaim 28 wherein in said analysing step, usernames and passwords areidentified from the field names of data contained in at least one ofsaid outbound data and said inbound data.
 30. The method of claim 28wherein a representation of the input fields of a web page is stored insaid memory of said one or more workstations, and wherein in saidanalysing step usernames and passwords are identified from saidrepresentation.
 31. The method of claim 28 wherein in said analysingstep usernames or passwords are identified from the field types of datacontained in said outbound or said inbound data.
 32. The method of claim27 wherein in said analysing step, digital certificates contained in atleast one of said outbound or said inbound data or used to digitallysign signed data in said inbound or said outbound data, are identifiedas relevant data, or sufficient descriptive data to identify suchdigital certificates, is identified as relevant data.
 33. The method ofclaim 32 wherein said analysing step includes identifying one or more ofthe following data as relevant data: whether or not said digitalcertificate has been revoked; the identity of the holder of said digitalcertificate; the amount of any eCommerce transaction being made that isrelated to said digital certificate; the goods or services being sold inany eCommerce transaction being made with said digital certificate; andthe date of receipt of said digital certificate.
 34. The method of claim27 wherein said analysing step includes identifying when an eCommercetransaction is occurring and if an on-line eCommerce transaction isidentified as occurring, identifying in said outbound or said inbounddata one or more of the following data as relevant data: the URL addressor e-mail address of the remote location to which outbound data is beingtransmitted or inbound data is being received; the web pages accessed bya user of said one or more workstations during the transaction; theamount of the transaction; the goods or services being traded in thetransaction; the date of the transaction.
 35. The method of claim 24wherein said analysing step is carried out at said one or moreworkstations.
 36. The method of claim 24 wherein said application is aweb browser.
 37. The method of claim 36 wherein said analysing step isperformed by a plug-in module of said web browser.
 38. The method ofclaim 37 wherein said web browser is Microsoft's Internet Explorer andsaid plug-in module is a Browser Helper Object.
 39. The method of claim24 wherein said application is an e-mail client.
 40. The method of claim39 wherein said analysing step is performed by a plug-in module of saide-mail client.
 41. The method of claim 40 wherein said e-mail client isMicrosoft's Outlook e-mail client and said plug-in module is a MicrosoftExchange client extension.
 42. The method of claim 24 wherein saidnetwork includes a server and said analysing step is performed at apoint on said network intermediate said one or more workstations andsaid server, or said analysing step is performed at said server.
 43. Themethod of claim 24 further comprising the step of providing a supervisorworkstation, said supervisor workstation having access to said datarepository and being operable to view said relevant data stored in saiddata repository.
 44. The method of claim 43 wherein said policy data isaccessible by said supervisor workstation, such that a user of saidsupervisor workstation can edit said policy data.
 45. The method ofclaim 24 wherein a workstation of said plurality of workstations hasaccess to said data repository and is operable to view said relevantdata stored in said data repository.
 46. The method of claim 24 whereinsaid computer network to which said one or more workstations are adaptedfor connection is a public computer network, and wherein said one ormore workstations together form a private computer network.
 47. Acomputer program product, for controlling a plurality of computers in aprivate network to manage information, the network having a datarepository arranged to receive data from the plurality of computers andpolicy data containing rules defining relevant data which is to beextracted from at least one of outbound data transmitted to a publicnetwork or inbound data received from the public network and stored inthe data repository, comprising: a recording medium readable by thecomputer, having program code recorded thereon which when executed oneach of said plurality of computers, configures said computers to:analyses in conjunction with an application running on each of saidcomputers that is operable to transmit the outbound data and receive theinbound data, at least one of said outbound data and said inbound data,with reference to said policy data, to identify in at least one of saidoutbound data and said inbound data, relevant data that is to be storedin said data repository in accordance with said rules in said policydata; and cause said relevant data to be stored in said data repository.48. The computer program product of claim 47 wherein said program codewhen executed on said computer is operable to cause said relevant datathat is to be stored in said data repository to be encrypted prior to itbeing stored in said data repository.
 49. The computer program productof claim 47 wherein said program code when executed on said computer isoperable to cause said relevant data that is stored in said datarepository to be encrypted.
 50. The computer program product of claim 47wherein said application is adapted to transmit outbound data to theInternet and receive inbound data from the Internet.
 51. The computerprogram product of claim 50 wherein at least one of usernames andpasswords used to identify a user, and usernames and passwords used toaccess web pages on the Internet, and the URL address of those webpages, are identified as relevant data.
 52. The computer program productof claim 51 wherein usernames and passwords are identified from thefield names of data contained in at least one of said outbound data andsaid inbound data.
 53. The computer program product of claim 51 whereina representation of the input fields of a web page is stored in saidmemory of said one or more workstations, and wherein said usernames andpasswords are identified from said representation.
 54. The computerprogram product of claim 51 wherein usernames or passwords areidentified from the field types of data contained in said outbound orsaid inbound data.
 55. The computer program product of claim 50 whereindigital certificates contained in at least one of said outbound or saidinbound data or used to digitally sign signed data in said inbound dataor said outbound data, or sufficient descriptive data to identify anysuch digital certificates, are identified as relevant data.
 56. Thecomputer program product of claim 55 wherein one or more of thefollowing data are identified as relevant data: whether or not saiddigital certificate has been revoked; the identity of the holder of saiddigital certificate; the amount of any eCommerce transaction being madethat is related to said digital certificate; the goods or services beingsold in any eCommerce transaction being made with said digitalcertificate; and the date of receipt of said digital certificate. 57.The computer program product of claim 50 wherein the program code whenexecuted on said computer is further operable to: identify when aneCommerce transaction is occurring; and if an eCommerce transaction isidentified as occurring, to identify in said outbound or said inbounddata one or more of the following data as relevant data: the URL addressor e-mail address of the remote location to which outbound data is beingtransmitted or inbound data is being received; the web pages accessed bya user of said one or more workstations during the transaction; theamount of the transaction; the goods or services being traded in thetransaction; and the date of the transaction.
 58. The computer programproduct of claim 47 wherein said program code is executable at each ofsaid computers.
 59. The computer program product of claim 47 whereinsaid application is a web browser.
 60. The computer program product ofclaim 59 wherein said program code when executed on said computer is aplug-in module of said web browser.
 61. The computer program product ofclaim 60 wherein said web browser is Microsoft's Internet Explorer andsaid plug-in module is a Browser Helper Object.
 62. The computer programproduct of claim 47 wherein said application is an e-mail client. 63.The computer program product of claim 62 wherein said program code whenexecuted on said computer is a plug-in module of said e-mail client. 64.The computer program product of claim 63 wherein said e-mail client isMicrosoft's Outlook e-mail client and said plug-in module is a MicrosoftExchange client extension.
 65. The computer program product of claim 47wherein said network includes a server and said program code isexecutable at a point on said network intermediate said one or moreworkstations and said server, or said program code is executable at saidserver.
 66. The computer program product of claim 47 further comprisingprogram code recorded on the recording medium which when executed on acomputer in said plurality of computers enables that computer as asupervisor workstation, said supervisor workstation having access tosaid data repository and being operable to view said relevant datastored in said data repository.
 67. The computer program product ofclaim 66 wherein said policy data is accessible by said supervisorworkstation, such that a user of said supervisor workstation can editsaid policy data.
 68. The computer program product of claim 47 furthercomprising program code recorded on the recording medium which whenexecuted on a computer in said plurality of computers provides thatcomputer with access to said data repository such that a users of saidcomputer can view said relevant data stored in said data repository. 69.A system for recording passwords and usernames comprising: a pluralityof workstations adapted for connection to the Internet, each workstationhaving a memory; a data repository arranged to receive data from each ofsaid workstations; an application stored in said memory of eachworkstation for transmitting outbound data and receiving inbound datafrom the Internet; and/or an application for receiving user input data;and an analyser, said analyser being operable to monitor at least one ofsaid input data, said outbound data and said inbound data, to identifyusernames and passwords contained in said user input data, said outbounddata or said inbound data, and to cause said usernames and passwords tobe stored in said data repository.
 70. The system of claim 69 whereinsaid analyser is operable to determine whether the usernames andpasswords are used to access a web page, and if they are, to identifythe URL address of said web page and cause said URL to be stored in saiddata repository with said usernames and passwords.
 71. The system ofclaim 69 wherein said relevant usernames and passwords data areencrypted prior to being transmitted to said data repository.
 72. Thesystem of claim 69 wherein said relevant usernames and passwords thatare stored in said data repository are encrypted.
 73. The system ofclaim 69 wherein said analyser is operable to identify said relevantusernames and passwords from the field names of data contained in atleast one of said outbound data or said inbound data.
 74. The system ofclaim 69 wherein a representation of the input fields of a web page isstored in said memory of said one or more workstations, and wherein saidanalyser is operable to identify said relevant usernames and passwordsfrom said representation.
 75. The system of claim 69 wherein saidanalyser is operable to identify said relevant usernames or passwordsfrom the field types of data contained in said outbound or said inbounddata.
 76. The system of claim 69 wherein said application has a userinterface provided with a ‘remember password’ option which when selectedstores input usernames and passwords in memory, and said analyser isoperable to identify said relevant usernames and passwords in said inputusernames and passwords stored in memory.
 77. The system of claim 69wherein said analyser is located on each of said one or moreworkstations.
 78. The system of claim 69 wherein said application is aweb browser.
 79. The system of claim 78 wherein said analyser is aplug-in module of said web browser.
 80. The system of claim 79 whereinsaid web browser is Microsoft's Internet Explorer and said analyser is aBrowser Helper Object.
 81. The system of claim 69 wherein said networkcomprises a server and said analyser is located at a point on saidnetwork intermediate said one or more workstations and said server, orsaid analyser is located at said server.
 82. The system of claim 69further comprising a supervisor workstation, said supervisor workstationhaving access to said data repository and being operable to view saidrelevant usernames and passwords stored in said data repository.
 83. Thesystem of claim 69 wherein a workstation of said plurality ofworkstations has access to said data repository and is operable to viewsaid relevant usernames and passwords stored in said data repository.84. A method for recording passwords and usernames comprising the stepsof: providing a plurality of workstations adapted for connection to theInternet, each workstation having a memory; providing a data repositoryarranged to receive data from each of said workstations; providing anapplication stored in said memory of each workstation for transmittingoutbound data and receiving inbound data from the Internet; and/or anapplication for receiving user input data; and analysing at least one ofsaid user input data, said outbound data and said inbound data, toidentify usernames and passwords; and causing said usernames andpasswords to be stored in said data repository.
 85. The method of claim84 further comprising the steps of determining whether the usernames andpasswords are used to access a web page, and if they are, identifyingthe URL address of said web page, and storing said URL in said datarepository with said usernames and passwords.
 86. The method of claim 84further comprising the step of encrypting usernames and passwords priorto being stored in said data repository.
 87. The method of claim 84further comprising the step of encrypting the usernames and passwordsthat are stored in said data repository.
 88. The method of claim 84wherein in said analysing step usernames and passwords are identifiedfrom the field names of data contained in at least one of said outbounddata or said inbound data.
 89. The method of claim 84 wherein arepresentation of the input fields of a web page is stored in saidmemory of said workstation, and wherein in said analyser step usernamesand passwords are identified from said representation.
 90. The method ofclaim 84 wherein in said analysing step usernames and passwords areidentified from the field types of data contained in said outbound orsaid inbound data.
 91. The method of claim 84 wherein said applicationhas a user interface provided with a ‘remember password’, option whichwhen selected stores input usernames and passwords in said memory ofsaid one or more workstations, and wherein in said analysing stepusernames and passwords are identified from said input usernames andpasswords stored in said memory of said one or more workstations. 92.The method of claim 84 wherein said analysing step is performed on saidone or more workstations.
 93. The method of claim 84 wherein saidapplication is a web browser.
 94. The method of claim 93 wherein saidanalysing step is performed by a plug-in module of said web browser. 95.The method of claim 94 wherein said web browser is Microsoft's InternetExplorer and said plug-in module is a Browser Helper Object.
 96. Themethod of claim 84 wherein said network comprises a server and saidanalysing step is performed at a point on said network intermediate saidone or more workstations and said server, or said analysing step isperformed at said server.
 97. The method of claim 84 further comprisingthe step of providing a supervisor workstation, said supervisorworkstation having access to said data repository and being operable toview said relevant usernames and passwords stored in said datarepository.
 98. The method of claim 84 wherein a computer of saidplurality of computers has access to said data repository and isoperable to view said relevant usernames and passwords stored in saiddata repository.
 99. A computer program product, for controlling aplurality of computers in a private network to record passwords andusernames, the network having a data repository arranged to receive datafrom the plurality of computers, said computer program productcomprising: a recording medium readable by the computer, having programcode recorded thereon which when executed on each of said plurality ofcomputers, configures said computers to: analyses, in conjunction withan application running on the computer that is operable to transmitoutbound data to the Internet and receive inbound data from theInternet, and/or an application running on the computer for receivinguser input data, at least one of said user input data, said outbounddata and said inbound data, to identify in at least one of said userinput data, said outbound data and said inbound data, relevant data thatis to be stored in said data repository; and control said computer tostore said relevant data in said data repository.
 100. The computerprogram product of claim 99 wherein said program code when executed onsaid computer is further operable to determine whether the usernames andpasswords are used to access a web page, and if they are, to identifythe URL address of said web page and to direct the computer to storesaid URL in said data repository with said usernames and passwords. 101.The computer program product of claim 99 wherein said program code whenexecuted on said computer is further operable to cause said usernamesand passwords to be encrypted prior to them being stored in said datarepository.
 102. The computer program product of claim 99 wherein saidprogram code when executed on said computer is further operable to causesaid usernames and passwords that are stored in said data repository tobe encrypted.
 103. The computer program product of claim 99 wherein saidprogram code when executed on said computer is operable to identifyusernames and passwords from the field names of data contained in atleast one of said outbound data or said inbound data.
 104. The computerprogram product of claim 99 wherein a representation of the input fieldsof a web page is stored in the memory of said computer, and wherein saidprogram code when executed on said computer is operable to identifyusernames and passwords from said representation.
 105. The computerprogram product of claim 99 wherein said program code when executed onsaid computer is further operable to identify usernames and passwordsfrom the field types of data contained in said outbound or said inbounddata.
 106. The computer program product of claim 99 wherein saidapplication for receiving user input data has a user interface providedwith a ‘remember password’ option which when selected stores inputusernames and passwords in said memory of said computer, and whereinsaid program code when executed on said computer is operable to identifyusernames and passwords from said input usernames and passwords storedin said memory of said computer.
 107. The computer program product ofclaim 99 wherein said program code is executable at each of saidcomputers.
 108. The computer program product of claim 99 wherein saidapplication is a web browser.
 109. The computer program product of claim108 wherein said program code when executed on said computer is aplug-in module of said web browser.
 110. The computer program product ofclaim 109 wherein said web browser is Microsoft's Internet Explorer andsaid plug-in module is a Browser Helper Object.
 111. The computerprogram product of claim 99 wherein said network comprises a server andsaid program code is executable at a point on said network intermediatesaid computer and said server, or said program code is executable atsaid server.
 112. The computer program product of claim 99 furthercomprising program code which when executed on said computer enablesthat computer as a supervisor workstation, said supervisor workstationhaving access to said data repository and being operable to view saidrelevant usernames and passwords stored in said data repository. 113.The computer program product of claim 99 wherein a computer of saidplurality of computers has access to said data repository and isoperable to view said relevant usernames and passwords stored in saiddata repository.
 114. An information management system comprising: oneor more workstations adapted for connection to a computer network, eachworkstation having a memory; an application stored in said memory ofeach workstation for transmitting outbound data to said network andreceiving inbound data from said network; policy data containing rulesspecifying an appropriate encryption strength for outbound data, theencryption strength depending on the content of the data; and ananalyser, said analyser being operable in conjunction with said policydata to monitor said outbound data and to determine, in accordance withsaid rules in said policy data, an appropriate encryption strength forthe outbound data; wherein said analyser controls transmission of saidoutbound data from said application in dependence upon saiddetermination of an appropriate encryption strength.
 115. The system ofclaim 114 wherein said rules in said policy data define confidentialdata which can not be transmitted, said analyser being operable inconjunction with said policy data to prevent said confidential databeing transmitted from said application.
 116. The system of claim 114wherein said analyser is further operable to determine the presentencryption strength in use for transmitting said outbound data; andwherein said analyser controls transmission of said outbound data fromsaid application both in dependence upon said determination of anappropriate encryption strength and in dependence upon saiddetermination of the present encryption strength in use.
 117. The systemof claim 116 wherein if the analyser determines that the presentencryption strength in use for transmitting outbound data is less thansaid appropriate encryption strength, then said analyser preventstransmission of said outbound data from said application.
 118. Thesystem of claim 116 wherein if the analyser determines that the presentencryption strength in use for transmitting outbound data is less thansaid appropriate encryption strength, then said analyser preventstransmission of said outbound data from said application and controlssaid application to renegotiate an encryption strength for transmissionthat is appropriate.
 119. The system of claim 116 wherein if theanalyser determines that the present encryption strength in use fortransmitting outbound data is less than said appropriate encryptionstrength, then said analyser modifies the outbound data such that thepresent encryption strength is an appropriate encryption strength forthe transmission of the modified outbound data.
 120. The system of claim116 wherein if the analyser determines that the present encryptionstrength in use for transmitting outbound data is less than saidappropriate encryption strength, then said analyser controls saidapplication to notify a user of said application that the encryptionstrength in use is not sufficient.
 121. The system of claim 114 whereinthe analyser is further operable to identify credit card numbers in saidoutbound data.
 122. The system of claim 121 wherein the analyser isfurther operable to distinguish a predetermined set of credit cardnumbers from other credit card numbers, wherein said rules of saidpolicy data define different appropriate encryption strengths foroutbound data containing credit card numbers in the predetermined setthan for other credit card numbers.
 123. The system of claim 122 whereinsaid rules of said policy data specify that there is no appropriateencryption strength for a pre-determined set of one or more credit cardnumbers.
 124. The system of claim 114 wherein said analyser is furtheroperable to identify at least one or more of, credit card numbers,account codes, usernames, passwords, names and addresses and otherpredetermined keywords in the content of said outbound data.
 125. Thesystem of claim 114 wherein said rules in said policy data specify anappropriate encryption strength for said outbound data, that isdependent on the address to which said outbound data is to betransmitted.
 126. The system of claim 114 wherein said analyser islocated on each of said one or more workstations.
 127. The system ofclaim 114 wherein said application is a web browser.
 128. The system ofclaim 127 wherein said analyser is a plug-in module of said web browser.129. The system of claim 128 wherein said web browser is Microsoft'sInternet Explorer and said analyser is a Browser Helper Object.
 130. Thesystem of claim 114 wherein said application is an e-mail client. 131.The system of claim 130 wherein said analyser is a plug-in module ofsaid e-mail client.
 132. The system of claim 131 wherein said e-mailclient is Microsoft's Outlook e-mail client and said analyser is aMicrosoft client extension.
 133. The system of claim 114 wherein saidnetwork comprises a server and said analyser is located at a point onsaid network intermediate said one or more workstations and said server,or said analyser is located at said server.
 134. The system of claim 114wherein said computer network to which said one or more workstations areadapted for connection is a public computer network, and wherein saidone or more workstations together form a private computer network. 135.The system of claim 114 further comprising a supervisor workstation,said policy data being accessible by said supervisor workstation, suchthat a user of said supervisor workstation can edit said policy data.136. A method of managing information comprising the steps of: providingone or more workstations adapted for connection to a computer network,each workstation having a memory; providing an application stored insaid memory of each workstation for transmitting outbound data to saidnetwork and receiving inbound data from said network; providing policydata containing rules specifying an appropriate encryption strength foroutbound data, the encryption strength depending on the content of thedata; and analysing said outbound data to determine, in accordance withsaid rules in said policy data, an appropriate encryption strength forthe outbound data; controlling transmission of said outbound data fromsaid application in dependence upon the determination of an appropriateencryption strength in said analysing step.
 137. The method of claim 136wherein said rules in said policy data define confidential data whichcannot be transmitted, and wherein in said controlling step transmissionof said confidential data is prevented.
 138. The method of claim 136wherein said analysing step further comprising the step of determiningthe present encryption strength in use for transmitting said outbounddata; and wherein in said controlling step the transmission of saidoutbound data from said application is dependent upon both thedetermination of an appropriate encryption strength and thedetermination of the present encryption strength in use.
 139. The methodof claim 138 wherein if it is determined that the present encryptionstrength in use for transmitting outbound data is less than saidappropriate encryption strength, then in said controlling steptransmission of said outbound data from said application is prevented.140. The method of claim 138 wherein if in said analysing step it isdetermined that the present encryption strength in use for transmittingoutbound data is less than said appropriate encryption strength, then insaid controlling step an encryption strength appropriate fortransmission of said outbound data is negotiated before transmission.141. The method of claim 138 wherein if in said analysing step it isdetermined that the present encryption strength in use for transmittingoutbound data is less than said appropriate encryption strength, then insaid controlling step the outbound data is modified such that thepresent encryption strength is an appropriate encryption strength. 142.The method of claim 138 wherein in said analysing step if it isdetermined that the present encryption strength in use for transmittingoutbound data is less than said appropriate encryption strength, then insaid controlling step a user of said application is notified that theencryption strength in use is not sufficient.
 143. The method of claim136 wherein said analysing step includes identifying credit card numbersin said outbound data.
 144. The method of claim 143 wherein saidanalysing step includes distinguishing a pre-determined set of one ormore credit card numbers from other credit card numbers, and whereinsaid rules of said policy data define a different appropriate encryptionstrength for outbound data containing credit card numbers in thatpre-determined set than for other credit card numbers.
 145. The methodof claim 144 wherein said rules of said policy data specifies that thereis no appropriate encryption strength for said pre-determined set of oneor more credit card numbers.
 146. The method of claim 136 wherein saidanalysing step includes identifying at least one or more of, credit cardnumbers, account codes, usernames, passwords, names and addresses andother predetermined keywords in the content of said outbound data. 147.The method of claim 136 wherein said rules in said policy data specifyan appropriate encryption strength for said outbound data, that isdependent on the address to which said outbound data is to betransmitted.
 148. The method of claim 136 wherein said analysing step isperformed at said one or more workstations.
 149. The method of claim 136wherein said application is a web browser.
 150. The method of claim 149wherein said analysing step is performed by a plug-in module of said webbrowser.
 151. The method of claim 150 wherein said web browser isMicrosoft's Internet Explorer and said plug-in module is a BrowserHelper Object.
 152. The method of claim 136 wherein said application isan e-mail client.
 153. The method of claim 152 wherein said analysingstep is performed by a plug-in module of said e-mail client.
 154. Themethod of claim 153 wherein said e-mail client is Microsoft's Outlooke-mail client and said plug-in module is a Microsoft Exchange clientextension.
 155. The method of claim 136 wherein said network comprises aserver and said analysing step is performed at a point on said networkintermediate said one or more workstations and said server, or saidanalysing step is performed at said server.
 156. The method of claim 136wherein said computer network to which said one or more workstations areadapted for connection is a public computer network, and wherein saidone or more workstations together form a private computer network. 157.The method of claim 136 further comprising the step of providing asupervisor workstation, said policy data being accessible by saidsupervisor workstation, such that a user of said supervisor workstationcan edit said policy data.
 158. A computer program product forcontrolling a computer connected to a public network to manageinformation, the computer having access to policy data containing rulesspecifying an appropriate encryption strength for outbound datatransmitted to the public network, the encryption strength depending onthe content of the data, comprising: a recording medium readable by thecomputer, having program code recorded thereon which when executed onsaid computer, configures said computer to: determine, in conjunctionwith an application running on the computer that is operable at least totransmit outbound data to said public network, with reference to saidrules in said policy data, an appropriate encryption strength for theoutbound data; and control the transmission of said outbound data bysaid application in dependence upon the determination of an appropriateencryption strength.
 159. The computer program product of claim 158wherein said rules in said policy data define confidential data whichcannot be transmitted, wherein said program code when executed on saidcomputer is operable to prevent transmission of said confidential datafrom said application.
 160. The computer program product of claim 158wherein said program code when executed on said computer is furtheroperable to determine the present encryption strength in use fortransmitting said outbound data; and to control the transmission of saidoutbound data from said application in dependence upon both thedetermination of an appropriate encryption strength and thedetermination of the present encryption strength in use.
 161. Thecomputer program product of claim 160 wherein said program code whenexecuted on said computer is further operable, if it is determined thatthe present encryption strength in use for transmitting outbound data isless than said appropriate encryption strength, to prevent thetransmission of said outbound data from said application.
 162. Thecomputer program product of claim 160 wherein said program code whenexecuted on said computer is further operable, if it is determined thatthe present encryption strength in use for transmitting outbound data isless than said appropriate encryption strength, to negotiate anappropriate encryption strength for transmission of said outbound databefore transmission.
 163. The computer program product of claim 160wherein said program code when executed on said computer is furtheroperable, if it is determined that the present encryption strength inuse for transmitting outbound data is less than said appropriateencryption strength, to modify the outbound data such that the presentencryption strength is an appropriate encryption strength.
 164. Thecomputer program product of claim 160 wherein said program code whenexecuted on said computer is further operable, if it is determined thatthe present encryption strength in use for transmitting outbound data isless than said appropriate encryption strength, to provide notificationthat the encryption strength in use is not sufficient.
 165. The computerprogram product of claim 158 wherein said program code when executed onsaid computer is further operable to identify credit card numbers insaid outbound data.
 166. The computer program product of claim 165wherein said program code when executed on said computer is furtheroperable to identify a pre-determined set of one or more credit cardnumbers from other credit card numbers, and wherein said rules of saidpolicy data define a different appropriate encryption strength foroutbound data containing credit card numbers in that pre-determined setthan for other credit card numbers.
 167. The computer program product ofclaim 166 wherein said rules of said policy data specifies that there isno appropriate encryption strength for said pre-determined set of one ormore credit card numbers.
 168. The computer program product of claim 158wherein said program code when executed on said computer is furtheroperable, to identify at least one or more of, credit card numbers,account codes, usernames, passwords, names and addresses and otherpredetermined keywords in the content of said outbound data.
 169. Thecomputer program product of claim 158 wherein said rules in said policydata specify an appropriate encryption strength for said outbound data,that is dependent on the address to which said outbound data is to betransmitted.
 170. The computer program product of claim 158 wherein saidprogram code is executable on said computer.
 171. The computer programproduct of claim 158 wherein said application is a web browser.
 172. Thecomputer program product of claim 171 wherein said program code whenexecuted on said computer is a plug-in module of said web browser. 173.The computer program product of claim 172 wherein said web browser isMicrosoft's Internet Explorer and said plug-in module is a BrowserHelper Object.
 174. The computer program product of claim 158 whereinsaid application is an e-mail client.
 175. The computer program productof claim 174 wherein said program code when executed on said computer isa plug-in module of said e-mail client.
 176. The computer programproduct of claim 175 wherein said e-mail client is Microsoft's Outlooke-mail client and said plug-in module is a Microsoft Exchange clientextension.
 177. The computer program product of claim 158 wherein saidnetwork includes a server and said program code is executable at a pointon said network intermediate said one or more workstations and saidserver, or program code is executable at said server.
 178. Aninformation management system comprising: a plurality of clientworkstations adapted for connection to a computer network, eachworkstation having a memory; a data repository arranged to receive datafrom each of said client workstations; an application stored in saidmemory of each workstation for transmitting outbound data to saidnetwork and receiving inbound data from said network; policy datadefining rules for the recording of data that may comprise part of atransaction conducted between a client workstation and a third partyacross said computer network; an analyser, said analyser being operablein conjunction with said policy data to analyse at least one of saidoutbound data and said inbound data, to identify the existence of atransaction occurring between a client workstation and a third party byanalysing said outbound or said inbound data, and to cause transactiondata that is all or part of said outbound data or said inbound datarelated to an identified transaction to be stored in said datarepository.
 179. The system of claim 178 wherein said analyser isoperable to determine whether a secure link has been negotiated betweensaid application and a remote site on said network, and to identify theexistence of a transaction if said outbound data or said inbound data istransmitted on a secure link.
 180. The system of claim 179 wherein saidnetwork is the Internet, and said rules of said policy data define theaddresses of non-eCommerce web sites and/or non-eCommerce e-mailaccounts, said analyser being operable to disregard any transactionsthat are identified between a client workstation and a non-eCommerce website and/or e-mail account such that no transaction data related to atransaction made to a non-eCommerce web sites or a non-eCommerce e-mailaccount is stored in the data repository.
 181. The system of claim 178wherein said analyser is operable to identify the existence of atransaction by reference to said rules of said policy data, said rulesof said policy data defining the addresses of known eCommerce locations.182. The system of claim 178 wherein said analyser is operable toidentify credit card numbers, and to identify the existence of atransaction by identifying credit card numbers in said outbound data orinbound data.
 183. The system of claim 178 wherein said analyser isoperable to identify the existence of a transaction by reference to saidrules of said policy data, said rules of said policy data defining oneor more of pre-determined digital certificates, account codes,pre-determined keywords, pre-determined names and addresses and embeddedcodes.
 184. The system of claim 178 wherein said analyser is operable toidentify embedded codes in said inbound data, said embedded code havingbeen placed in said inbound data to identify it as transaction data.185. The system of claim 178 wherein said analyser is operable toidentify electronic receipts, and to identify the existence of atransaction by identifying an electronic receipt in said outbound orinbound data.
 186. The system of claim 178 wherein said analyser isoperable to record a pre-determined number of subsequent transmissionsof said outbound data or said inbound data following an identificationof the existence of a transaction by said analyser, providing that theaddress or organisation to which the subsequent transmissions are sent,or from which they are received, is the same as the address ororganisation to which the outbound data was sent or from which theinbound data was received and in which the existence of a transactionwas identified.
 187. The system of claim 186, wherein said analyser isoperable to detect one or more indicators of the nature of thetransaction, and said rules of said policy data define the number ofsubsequent transmissions of said outbound data and said inbound datathat are to be recorded in said data repository based on the identifiednature of the transaction.
 188. The system of claim 186 wherein saidrules of said policy data define the number of subsequent transmissionsof said outbound and said inbound data that are to be stored in saiddata repository in dependence on the indicator by which the existence ofa transaction was identified.
 189. The system of claim 178 wherein saidanalyser is operable to record all subsequent transmissions of saidoutbound data or said inbound data that occur within a pre-determinedamount of time following an identification of the existence of atransaction by said analyser, providing that the address or organisationto which the subsequent transmissions are sent, or from which they arereceived, is the same as the address or organisation to which theoutbound data was sent or from which the inbound data was received andin which the existence of a transaction was identified.
 190. The systemof claim 189, wherein said analyser is operable to detect one or moreindicators of the nature of the transaction, and said rules of saidpolicy data define the amount of time for which all subsequenttransmissions of said outbound data and said inbound data are to berecorded in said data repository based on the identified nature of thetransaction.
 191. The system of claim 189 wherein said rules of saidpolicy data define the amount of time for which subsequent transmissionsof said outbound and said inbound data are to be stored in said datarepository in dependence on the indicator by which the existence of atransaction was identified.
 192. The system of claim 178 wherein saidanalyser is further operable to identify the completion of a transactionby analysing said outbound data or said inbound data, and to cause allor part of said outbound data transmitted by said application and all orpart of said inbound data received by said application after saidanalyser has identified the existence of a transaction and before saidanalyser has identified the completion of a transaction to be stored insaid data repository.
 193. The system of claim 192 wherein said analyseris operable to identify subsequent related data in said outbound datatransmitted by said application and said inbound data received by saidapplication after said analyser has identified the completion of atransaction, and to cause said subsequent related data to be stored insaid data repository with said transaction data already identified. 194.The system of claim 193 wherein said analyser is operable to identifysaid subsequent related data by identifying common indicators in bothsaid transaction data already identified and said outbound datatransmitted by said application and said inbound data received by saidapplication after said analyser has identified the completion of atransaction, said common indicators being one or more of the address ofthe location to which said outbound data is transmitted or from whichsaid inbound data is received, part of the data path to the location towhich said outbound data is transmitted or from which said inbound datais received, account code or reference numbers.
 195. The system of claim178 wherein said application is operable such that a user of saidapplication can indicate said outbound and said inbound data that isrelated to a transaction, said analyser being operable to identify saidoutbound and said inbound data so indicated.
 196. The system of claim178 wherein said application is operable to store all of said outbounddata and said inbound data in said memory of said workstation asprevious data, irrespective of whether it may or may not be part of atransaction and, said analyser is operable, if the existence of atransaction is identified, to retrieve a pre-determined amount ofprevious data from said outbound data and said inbound data stored insaid memory of said workstation, and to cause said previous data to bestored in said data repository with said transaction data.
 197. Thesystem of claim 196 wherein said rules of said policy data specify theamount of previous data that is to be retrieved in dependence on theindicator by which the existence of a transaction is identified. 198.The system of claim 196 wherein said network is the Internet and saidapplication is a web browser, said web browser being operable to storeeach web page that is viewed by said web browser in memory as previousdata.
 199. The system of claim 198 wherein said rules of said policydata specify the number of web pages that are to be retrieved from thosepreviously stored in memory in dependence on the indicator by which theexistence of a transaction is identified.
 200. The system of claim 178wherein said application is operable to store all of said outbound dataand said inbound data in memory as previous data, irrespective ofwhether it may or may not be part of a transaction and, said analyser isoperable, if the existence of a transaction is identified, to identify,in said previous data, earlier relevant data that is related to saidtransaction data already identified, and to cause said earlier relevantdata to be stored in said data repository with said transaction data.201. The system of claim 200 wherein said analyser is operable toidentify said earlier relevant data in said previous data, byidentifying common indicators in both said transaction data and saidoutbound data and said inbound data previously stored in said memory ofsaid workstation, said common indicators being one or more of theaddress of the location to which said outbound data is transmitted orfrom which said inbound data is received, part of the data path to thelocation to which said outbound data is transmitted or said inbound datais received, account code or reference number.
 202. The system of claim178 wherein said application is operable to store all of said outbounddata and said inbound data in memory as previous data, irrespective ofwhether it may or may not be part of a transaction, and is furtheroperable such that, if said analyser identifies the existence of atransaction, a user of said application can select earlier relevant datafrom said previous data, said earlier relevant data selected by the userbeing stored in said common data repository together with saidtransaction data.
 203. The system of claim 178 wherein said analyser isoperable, once it has identified the existence of a transaction, todetermine the nature of said transaction by analysing the content ofsaid outbound and inbound data, and said rules of said policy datadefine how said transaction data is to be stored in said data repositoryin dependence on the nature of the transaction determined by saidanalyser, said transaction data being stored in said database accordingto said determination and said rules of said policy data.
 204. Thesystem of claim 203 wherein said analyser is operable to determine thenature of the transaction by identifying in said outbound data and saidinbound data one or more indicators, said indicators being defined insaid rules of said policy data, and being one or more of: the address ofthe network location to which said data that may be part of atransaction is transmitted or from which it is received; part of thedata path to the network location to which said transaction data istransmitted or from which it is received; account codes; referencenumbers; credit card numbers; digital certificates and pre-determinedkeywords.
 205. The system of claim 178 wherein said analyser is operableto identify, once the existence of a transaction has been identified,one or more indicators of the nature of said transaction, saidtransaction data being stored in said data repository such that it isorganised by said one or more indicators to form a record.
 206. Thesystem of claim 205 wherein said rules of said policy data define saidone or more indicators of the nature of a transaction, said indicatorsbeing one or more of: the address of the location to which saidtransaction data is transmitted or from which it is received; part ofthe data path to the location to which said transaction data istransmitted or from which it is received; account codes, referencenumbers, credit card numbers, digital certificates and pre-determinedkeywords.
 207. The system of claim 178 wherein said data repository isaccessible by one or more of an accounts application, an orderprocessing application or other transaction management application. 208.The system of claim 178 wherein any data transmitted to said datarepository is encrypted before it is transmitted to said datarepository.
 209. The system of claim 178 wherein any data stored in saiddata repository is encrypted.
 210. The system of claim 178 wherein saidanalyser is located on each of said one or more workstations.
 211. Thesystem of claim 178 wherein said application is a web browser.
 212. Thesystem of claim 211 wherein said analyser is a plug-in module of saidweb browser.
 213. The system of claim 212 wherein said web browser isMicrosoft's Internet Explorer and said analyser is a Browser HelperObject.
 214. The system of claim 178 wherein said application is ane-mail client.
 215. The system of claim 214 wherein said analyser is aplug-in module of said e-mail client.
 216. The system of claim 215wherein said e-mail client is Microsoft's Outlook e-mail client and saidanalyser is a Microsoft Exchange client extension.
 217. The system ofclaim 178 wherein said network comprises a server, and said analyser islocated at a point on said network intermediate said one or more workstations and said server, or said analyser is located at said server.218. The system of claim 178 wherein said computer network to which saidone or more workstations are adapted for connection is a public computernetwork, and wherein said one or more workstations together form aprivate computer network.
 219. The system of claim 178 furthercomprising a supervisor workstation, said policy data being accessibleby said supervisor workstation, such that a user of said supervisorworkstation can edit said policy data.
 220. A method of managinginformation comprising the steps of: providing a plurality of clientworkstations adapted for connection to a computer network, eachworkstation having a memory; providing a data repository arranged toreceive data from each of said client workstations; providing anapplication stored in said memory of each workstation for transmittingoutbound data to said network and receiving inbound data from saidnetwork; providing policy data defining rules for the recording of datathat may comprise part of a transaction conducted between a clientworkstation and a third party across said computer network; andanalysing, at least one of said outbound data and said inbound data toidentify, with reference to said rules of said policy data, theexistence of a transaction occurring between a client workstation and athird party; and storing transaction data that is all or part of saidoutbound data or said inbound data related to an identified transactionin said data repository.
 221. The method of claim 220 wherein in saidanalysing step the existence of a transaction is identified bydetermining whether a secure link has been negotiated between saidapplication and a remote site on said network, and by determiningwhether said outbound data or said inbound data is transmitted on thatlink.
 222. The method of claim 221 wherein said network is the Internet,and said rules of said policy data define the addresses of non-eCommerceweb sites and/or non-eCommerce e-mail accounts, wherein said analysingstep includes disregarding any transactions that are identified betweena client workstation and a non-eCommerce web site and/or e-mail accountsuch that no transaction data related to a transaction made to anon-eCommerce web site or a non-eCommerce e-mail account is stored inthe data repository.
 223. The method of claim 220 wherein said analysingstep includes identifying the existence of a transaction by reference tosaid rules of said policy data, said rules of said policy data definingthe addresses of known eCommerce locations.
 224. The method of claim 220wherein said analysing step includes identifying credit card numbers,and the existence of a transaction is identified by identifying creditcard numbers in said outbound data or inbound data.
 225. The method ofclaim 220 wherein in said analysing step the existence of a transactionis identified by reference to said rules of said policy data, said rulesof said policy data defining one or more of pre-determined digitalcertificates, account codes, pre-determined keywords, pre-determinednames and addresses and embedded codes.
 226. The method of claim 220wherein said analysing step includes detecting an embedded code in saidinbound data, said embedded code having been placed in said inbound datato identify it as transaction data.
 227. The method of claim 220 whereinin said analysing step, the existence of a transaction is identified byidentifying an electronic receipt in said outbound or inbound data. 228.The method of claim 220 further comprising the step of recording apre-determined number of subsequent transmissions of said outbound dataor said inbound data following an identification of the existence of atransaction in said analysing step, providing that the address ororganisation to which the subsequent transmissions are sent, or fromwhich they are received, is the same as the address or organisation towhich the outbound data was sent or from which the inbound data wasreceived and in which the existence of a transaction was identified.229. The method of claim 228, wherein said analysing step includesdetecting one or more indicators of the nature of the transaction, andsaid rules of said policy data define the number of subsequenttransmissions of said outbound data and said inbound data that are to berecorded in said data repository based on the identified nature of thetransaction.
 230. The method of claim 228 wherein said rules of saidpolicy data define the number of subsequent transmissions of saidoutbound and said inbound data that are to be stored in said datarepository in dependence on the indicator by which the existence of atransaction was identified.
 231. The method of claim 220 furthercomprising the step of recording all subsequent transmissions of saidoutbound data or said inbound data that occur within a pre-determinedamount of time following an identification of the existence of atransaction in said analysing step, providing that the address ororganisation to which the subsequent transmissions are sent, or fromwhich they are received, is the same as the address or organisation towhich the outbound data was sent or from which the inbound data wasreceived and in which the existence of a transaction was identified.232. The method of claim 231, wherein said analysing step includesdetecting one or more indicators of the nature of the transaction, andsaid rules of said policy data define the amount of time for which allsubsequent transmissions of said outbound data and said inbound data areto be recorded in said data repository based on the identified nature ofthe transaction.
 233. The method of claim 231 wherein said rules of saidpolicy data define the amount of time for which subsequent transmissionsof said outbound and said inbound data are to be stored in said datarepository in dependence on the indicator by which the existence of atransaction was identified.
 234. The method of claim 220 wherein saidanalysing step includes identifying the completion of a transaction byanalysing said outbound data or said inbound data, and said storing stepincludes storing all or part of said outbound data transmitted by saidapplication and all or part of said inbound data received by saidapplication, after the existence of a transaction has been identifiedand before the completion of a transaction has been identified, in saiddata repository.
 235. The method of claim 234 wherein said analysingstep includes identifying subsequent related data contained in saidoutbound data transmitted by said application and said inbound datareceived by said application after the completion of a transaction, andsaid storing step includes storing said subsequent related data in saiddata repository with said transaction data already identified.
 236. Themethod of claim 235 wherein said analysing step includes identifyingsaid subsequent related data by identifying common indicators in bothsaid transaction data already identified and said outbound datatransmitted by said application and said inbound data received by saidapplication after the completion of a transaction has been identified,said common indicators being one or more of the address of the locationto which said outbound data is transmitted or from which said inbounddata is received, part of the data path to the location to which saidoutbound data is transmitted or from which said inbound data isreceived, account code or reference numbers.
 237. The method of claim220 wherein said application is operable such that a user of saidapplication can indicate said outbound and said inbound data that isrelated to a transaction, said analysing step including identifyingindicated outbound and inbound data.
 238. The method of claim 220further comprising the step of storing all of said outbound data andsaid inbound data in said memory of said workstation as previous data,irrespective of whether it may or may not be part of a transaction and,said analysing step includes retrieving a pre-determined amount ofprevious data from said outbound data and said inbound data stored insaid memory of said workstation if the existence of a transaction isidentified, and said storing step includes storing said previous data insaid data repository with said transaction data.
 239. The method ofclaim 238 wherein said rules of said policy data specify the amount ofprevious data that is to be retrieved in dependence on the indicator bywhich the existence of a transaction is identified.
 240. The method ofclaim 238 wherein said network is the Internet and said application is aweb browser, said web browser being operable to store each web page thatis viewed by said web browser in memory as previous data.
 241. Themethod of claim 240 wherein said rules of said policy data specify thenumber of web pages that are to be retrieved from those previouslystored in memory in dependence on the indicator by which the existenceof a transaction is identified.
 242. The method of claim 220 furthercomprising the step of storing all of said outbound data and saidinbound data in memory as previous data, irrespective of whether it mayor may not be part of a transaction and, said analysing step includesidentifying, in said previous data, earlier relevant data that isrelated to said transaction data already identified, and said storingstep includes storing said earlier relevant data in said data repositorywith said transaction data.
 243. The method of claim 242 wherein saidanalysing step includes identifying said earlier relevant data in saidprevious data, by identifying common indicators in both said transactiondata and said previous data, said common indicators being one or more ofthe address of the location to which said outbound data is transmittedor from which said inbound data is received, part of the data path tothe location to which said outbound data is transmitted or said inbounddata is received, account code or reference number.
 244. The method ofclaim 220 further comprising the steps of storing all of said outbounddata and said inbound data in memory as previous data, irrespective ofwhether it may or may not be part of a transaction; and if the existenceof a transaction is identified, providing a user of said applicationwith a selector for selecting earlier relevant data from said previousdata, and wherein said storing step includes storing said earlierrelevant data selected by the user in said data repository together withsaid transaction data.
 245. The method of claim 220 wherein saidanalysing step includes, once the existence of a transaction has beenidentified, determining the nature of said transaction by analysing thecontent of said outbound and inbound data, said rules of said policydata defining how said transaction data is to be stored in said datarepository in dependence on the nature of the transaction determined insaid analysing step, said transaction data being stored in said databaseaccording to said determination and said rules of said policy data. 246.The method of 245 wherein said analysing step includes determining thenature of the transaction by identifying in said outbound data and saidinbound data one or more indicators, said indicators being defined insaid rules of said policy data, and being one or more of: the address ofthe network location to which said data that may be part of atransaction is transmitted or from which it is received; part of thedata path to the network location to which said transaction data istransmitted or from which it is received; account codes; referencenumbers; credit card numbers; digital certificates and pre-determinedkeywords.
 247. The method of claim 220 wherein said analysing stepincludes identifying, once the existence of a transaction has beenidentified, one or more indicators of the nature of said transaction,and said storing step includes organising transaction data stored insaid data repository by said one or more indicators such that it forms arecord.
 248. The method of claim 247 wherein said rules of said policydata define said one or more indicators of the nature of a transaction,said indicators being one or more of: the address of the location towhich said transaction data is transmitted or from which it is received;part of the data path to the location to which said transaction data istransmitted or from which it is received; account codes, referencenumbers, credit card numbers, digital certificates and pre-determinedkeywords.
 249. The method of claim 220 wherein said data repository isaccessible by one or more of an accounts application, an orderprocessing application or other transaction management application. 250.The method of claim 220 further comprising the step of encrypting anyrelevant data identified in said analysing step before it is stored insaid data repository.
 251. The method of claim 220 further comprisingthe step of encrypting the data stored in said data repository.
 252. Themethod of claim 220 wherein said analysing step is performed at said oneor more workstations.
 253. The method of claim 220 wherein saidapplication is a web browser.
 254. The method of claim 253 wherein saidanalysing step is performed by a plug-in module of said web browser.255. The method of claim 254 wherein said web browser is Microsoft'sInternet Explorer and said plug-in module is a Browser Helper Object.256. The method of claim 220 wherein said application is an e-mailclient.
 257. The method of claim 256 wherein said analysing step isperformed by a plug-in module of said e-mail client.
 258. The method ofclaim 257 wherein said e-mail client is Microsoft's Outlook e-mailclient and said plug-in module is a Microsoft Exchange client extension.259. The method of claim 220 wherein said network comprises a server,and said analysing step is performed at a point on said networkintermediate said one or more work stations and said server, or saidanalysing step is performed at said server.
 260. The method of claim 220wherein said computer network to which said one or more workstations areadapted for connection is a public computer network, and wherein saidone or more workstations together form a private computer network. 261.The method of claim 220 further comprising the step of providing asupervisor workstation, said policy data being accessible by saidsupervisor workstation, such that a user of said supervisor workstationcan edit said policy data.
 262. A computer program product forcontrolling a plurality of computers in a private network to manageinformation, the network having a data repository arranged to receivedata from the plurality of computers, and policy data defining rules forthe recording of data that may comprise part of a transaction conductedbetween a computer in the private network and a third party across apublic network, comprising: a recording medium readable by a computer,having program code recorded thereon which when executed on each of saidplurality of computers configures said computers to: analyse, inconjunction with an application running on the computer that is operableto transmit outbound data to said public network and receive inbounddata from said public network, at least one of said outbound data andsaid inbound data to identify, with reference to said rules of saidpolicy data, the existence of a transaction occurring between thecomputer and a third party; and to control said computer to storetransaction data that is all or part of said outbound data or saidinbound data related to an identified transaction in said datarepository.
 263. The computer program product of claim 262 wherein saidprogram code when executed on said computer is operable to identify theexistence of a transaction by determining whether a secure link has beennegotiated between said application and a remote site on said publicnetwork, and whether the outbound data or said inbound data istransmitted on that link.
 264. The computer program product of claim 263wherein said public network is the Internet, and said rules of saidpolicy data define the addresses of non-eCommerce web sites and/ornon-eCommerce e-mail accounts, wherein said program code when executedon said computer is operable to disregard any transactions that areidentified between the computer and a non-eCommerce web site and/ore-mail account such that no transaction data related to a transactionmade to a non-eCommerce web sites or a non-eCommerce e-mail account isstored in the data repository.
 265. The computer program product ofclaim 262 wherein said program code when executed on said computer isoperable to identify the existence of a transaction by reference to saidrules of said policy data, said rules of said policy data defining theaddresses of known eCommerce locations.
 266. The computer programproduct of claim 262 wherein said program code when executed on saidcomputer is operable to identify credit card numbers, and the existenceof a transaction is identified by identifying credit card numbers insaid outbound data or inbound data.
 267. The computer program product ofclaim 262 wherein said program code when executed on said computer isoperable to identify the existence of a transaction by reference to saidrules of said policy data, said rules of said policy data defining oneor more of pre-determined digital certificates, account codes,pre-determined keywords, pre-determined names and addresses and embeddedcodes.
 268. The computer program product of claim 262 wherein saidprogram code when executed on said computer is operable to identify insaid inbound data an embedded code, said embedded code having beenplaced in said inbound data to identify it as transaction data.
 269. Thecomputer program product of claim 262 wherein said program code whenexecuted on said computer is operable to identify the existence of atransaction by identifying an electronic receipt in said outbound orinbound data.
 270. The computer program product of claim 262 whereinsaid program code when executed on said computer is further operable tocontrol the computer to record a pre-determined number of subsequenttransmissions of said outbound data or said inbound data following anidentification of the existence of a transaction, providing that theaddress or organisation to which the subsequent transmissions aretransmitted, or from which they are received, is the same as the addressor organisation to which the outbound data was sent or from which theinbound data was received and in which the existence of a transactionwas identified.
 271. The computer program product of claim 270, whereinsaid program code when executed on said computer is operable to detectone or more indicators of the nature of the transaction, and said rulesof said policy data define the number of subsequent transmissions ofsaid outbound data and said inbound data that are to be recorded in thedata repository based on the identified nature of the transaction. 272.The computer program product of claim 270 wherein said rules of saidpolicy data define the number of subsequent transmissions of saidoutbound and said inbound data that are to be stored in said datarepository in dependence on the indicator by which the existence of atransaction was identified.
 273. The computer program product of claim262 wherein said program code when executed on said computer is operableto control the computer to record all subsequent transmissions of saidoutbound data or said inbound data that occur within a pre-determinedamount of time following an identification of the existence of atransaction, providing that the address or organisation to which thesubsequent transmissions are transmitted, or from which they arereceived, is the same as the address or organisation to which theoutbound data was transmitted or from which the inbound data wasreceived and in which the existence of a transaction was identified.274. The computer program product of claim 273 wherein said program codewhen executed on said computer is operable to detect one or moreindicators of the nature of the transaction, and said rules of saidpolicy data define the amount of time for which all subsequenttransmissions of said outbound data and said inbound data are to berecorded in said data repository based on the identified nature of thetransaction.
 275. The computer program product of claim 273 wherein saidrules of said policy data define the amount of time for which subsequenttransmissions of said outbound and said inbound data are to be stored insaid data repository in dependence on the indicator by which theexistence of a transaction was identified.
 276. The computer programproduct of claim 262 wherein said program code when executed on saidcomputer is operable to identify the completion of a transaction, andcontrol the computer to store all or part of said outbound datatransmitted by said application and all or part of said inbound datareceived by said application after the existence of a transaction hasbeen identified and before the completion of a transaction has been inidentified in said data repository.
 277. The computer program product ofclaim 276 wherein said program code when executed on said computer isoperable to identify subsequent related data contained in said outbounddata transmitted by said application and said inbound data received bysaid application after the completion of a transaction, and control thecomputer to store said subsequent related data in the data repositorywith said transaction data already identified.
 278. The computer programproduct of claim 277 wherein said program code when executed on saidcomputer is operable to identify said subsequent related data byidentifying common indicators in both said transaction data alreadyidentified and said outbound data transmitted by said application andsaid inbound data received by said application after the completion of atransaction has been identified, said common indicators being one ormore of the address of the location to which said outbound data istransmitted or from which said inbound data is received, part of thedata path to the location to which said outbound data is transmitted orfrom which said inbound data is received, account code or referencenumbers.
 279. The computer program product of claim 262 wherein saidapplication is operable such that a user of said application canindicate said outbound and said inbound data that is related to atransaction, said program code when executed on said computer beingoperable to identify said outbound and said inbound data so indicated.280. The computer program product of claim 262 wherein said program codewhen executed on said computer is operable to control the computer tostore all of said outbound data and said inbound data in memory asprevious data, irrespective of whether it may or may not be part of atransaction and, to retrieve a pre-determined amount of previous datafrom said outbound data and said inbound data stored in memory if theexistence of a transaction is identified, and to control the computer tostore said previous data in the data repository with said transactiondata.
 281. The computer program product of claim 280 wherein said rulesof said policy data specify the amount of previous data that is to beretrieved in dependence on the indicator by which the existence of atransaction is identified.
 282. The computer program product of claim280 wherein said public network is the Internet and said application isa web browser, said web browser being operable to store each web pagethat is viewed by said web browser in memory as previous data.
 283. Thecomputer program product of claim 282 wherein said rules of said policydata specify the number of web pages that are to be retrieved from thosepreviously stored in memory in dependence on the indicator by which theexistence of a transaction is identified.
 284. The computer programproduct of claim 262 wherein said program code when executed on saidcomputer is further operable to control the computer to store all ofsaid outbound data and said inbound data in memory as previous data,irrespective of whether it may or may not be part of a transaction and,to identify, in said previous data, earlier relevant data that isrelated to said transaction data already identified, and control thecomputer to store the earlier relevant data in the data repository withsaid transaction data.
 285. The computer program product of claim 284wherein said program code when executed on said computer is furtheroperable to identify said earlier relevant data in said previous data,by identifying common indicators in both said transaction data and saidprevious data, said common indicators being one or more of the addressof the location to which said outbound data is transmitted or from whichsaid inbound data is received, part of the data path to the location towhich said outbound data is transmitted or said inbound data isreceived, account codes or reference numbers.
 286. The computer programproduct of claim 262 wherein said program code when executed on saidcomputer is further operable to control the computer to store all ofsaid outbound data and said inbound data in memory as previous data,irrespective of whether it may or may not be part of a transaction; andwherein said computer program product further comprises a selector,recorded on said recording medium, said selector being operable toselect earlier relevant data from said previous data in response toinput from a user, and wherein said program code when executed on saidcomputer is further operable to control the computer to store saidearlier relevant data selected by the user in said data repositorytogether with said transaction data.
 287. The computer program productof claim 262 wherein said program code when executed on said computer isoperable, once the existence of a transaction has been identified, todetermine the nature of said transaction by analysing the content ofsaid outbound and inbound data, said rules of said policy data defininghow said transaction data is to be stored in said data repository independence on the nature of the transaction that has been determined,said transaction data being stored in said database according to saiddetermination and said rules of said policy data.
 288. The computerprogram product of claim 287 wherein said program code when executed onsaid computer is further operable to determine the nature of thetransaction by identifying in said outbound data and said inbound dataone or more indicators, said indicators being defined in said rules ofsaid policy data, and being one or more of: the address of the publicnetwork location to which said data that may be part of a transaction istransmitted or from which it is received; part of the data path to thepublic network location to which said transaction data is transmitted orfrom which it is received; account codes; reference numbers; credit cardnumbers; digital certificates and pre-determined keywords.
 289. Thecomputer program product of claim 262 wherein said program code whenexecuted on said computer is further operable, once the existence of atransaction has been identified, to identify one or more indicators ofthe nature of said transaction, and to control the computer to organisethe storage of said transaction data by said one or more indicators suchthat it forms a record.
 290. The computer program product of claim 289wherein said rules of said policy data define said one or moreindicators of the nature of a transaction, said indicators being one ormore of: the address of the public location to which said transactiondata is transmitted or from which it is received; part of the data pathto the public location to which said transaction data is transmitted orfrom which it is received; account codes, reference numbers, credit cardnumbers, digital certificates and pre-determined keywords.
 291. Thecomputer program product of claim 262 wherein the data repository isaccessible by one or more of an accounts application, an orderprocessing application or other transaction management application. 292.The computer program product of claim 262 wherein said program code whenexecuted on said computer is further operable to cause any identifiedrelevant data to be encrypted before it is stored in said datarepository.
 293. The computer program product of claim 262 wherein saidprogram code when executed on said computer is further operable to causeany relevant data stored in the data repository to be encrypted. 294.The computer program product of claim 262 wherein said program code isexecutable at each of said computers.
 295. The computer program productof claim 262 wherein said application is a web browser.
 296. Thecomputer program product of claim 295 wherein said program code whenexecuted on said computer is a plug-in module of said web browser. 297.The computer program product of claim 296 wherein said web browser isMicrosoft's Internet Explorer and said plug-in module is a BrowserHelper Object.
 298. The computer program product of claim 262 whereinsaid application is an e-mail client.
 299. The computer program productof claim 298 wherein said program code when executed on said computer isa plug-in module of said e-mail client.
 300. The computer programproduct of claim 299 wherein said e-mail client is Microsoft's Outlooke-mail client and said plug-in module is a Microsoft Exchange clientextension.
 301. Computer program product of claim 262 wherein saidnetwork includes a server and said program code is executable at a pointon said network intermediate said one or more workstations and saidserver, or said program code is executable at said server.
 302. Thecomputer program product of claim 262 further comprising program coderecorded on the recording medium which when executed on a computer inthe plurality of computers enable that computer as a supervisorworkstation, said supervisor workstation having access to said datarepository and being operable to view said relevant data stored in saiddata repository.
 303. The computer program product of claim 302 whereinsaid policy data is accessible by said supervisor workstation, such thata user of said supervisor workstation can edit said policy data.
 304. Aninformation management system comprising: one or more workstationsadapted for connection to a computer network, each workstation having amemory; an application stored in said memory of each workstation fortransmitting outbound data to said network and receiving inbound datafrom said network; policy data, containing rules for the transmission ofoutbound data that may be part of a transaction; and an analyser, saidanalyser being operable in conjunction with said policy data to identifyin at least said outbound data, transaction data that may be part of atransaction, and to make a determination in accordance with said rulesof said policy data as to whether the transmission of said transactiondata would satisfy said rules; and wherein the transmission of saidtransaction data by said application is dependent on said determinationmade by said analyser.
 305. The system of claim 304, wherein accordingto said determination made by said analyser, said transaction data iseither, transmitted, not transmitted, or sent to an approver whodetermines whether or not to transmit the transaction data.
 306. Thesystem of claim 305 further comprising: one or more approvers, fordeciding whether the transmission of said data that may be part of atransaction may be made; wherein said analyser is operable to identifyin said data that may be part of a transaction, data that needs approvaland to refer said data that needs approval to one of said one or moreapprovers; and the transmission of said data that needs approval beingdependent on the decision of said one or more approver.
 307. The systemof claim 306 wherein said analyser is operable to identify saidtransaction data that needs approval by determining the nature of saidtransaction data and by checking said rules of said policy data, saidrules of said policy data defining whether or not approval is needed independence on the determined nature of said transaction data.
 308. Thesystem of claim 306 wherein said analyser is operable to determine thenature of said transaction data by identifying at least one of theidentity of the transmitter of said data, the identity of the intendedrecipient of said data, the workstation from which said data is to betransmitted, the sum for which a transaction is to be made, and theaccount against which a transaction is to be made.
 309. The system ofclaim 306 wherein said analyser is operable to determine the nature ofsaid transaction data that needs approval and to select said one of saidone or more approvers in dependence on that determination.
 310. Thesystem of claim 309 wherein said analyser is operable to determine thenature of said transaction data that needs approval by identifying atleast one of the identity of the transmitter of said data, the identityof the intended recipient of said data, the work station from which saiddata is to be transmitted, the sum for which a transaction is to bemade, and the account against which the transaction is to be made. 311.The system of claim 304 wherein said analyser is operable to determinewhether a secure link has been negotiated between said application and aremote site on said network, and to identify said outbound data or saidinbound data as transaction data, if it is transmitted on a secure link.312. The system of claim 311 wherein said network is the Internet, andsaid rules of said policy data define the addresses of web sites ore-mail accounts that negotiate secure links for the transmission of databut which are known not to be eCommerce sites or accounts, said analyserbeing operable to disregard said outbound data transmitted to those websites or accounts or said inbound data received from those web sites oraccounts, such that no approval is required.
 313. The system of claim304 wherein said analyser is operable to identify transaction data byreference to said rules of said policy data, said rules of said policydata defining the addresses of known eCommerce web sites and e-mailaccounts.
 314. The system of claim 304 wherein said analyser is operableto identify credit card numbers in said outbound data or said inbounddata, and to identify outbound data or inbound data that contains acredit card number as transaction data.
 315. The system of claim 314wherein said policy data specifies pre-determined credit card numbersthat can never be transmitted.
 316. The system of claim 304 wherein saidanalyser is operable to identify transaction data by reference to saidrules of said policy data, said rules of said policy data defining oneor more of pre-determined digital certificates, account codes,pre-determined keywords, pre-determined names and addresses and embeddedcodes.
 317. The system of claim 304 wherein said analyser is operable toidentify embedded codes in said inbound data, said embedded codes havingbeen placed in said inbound data to mark said inbound data astransaction data.
 318. The system of claim 304 wherein said applicationis operable such that a user of said application can indicate saidoutbound and said inbound data that is part of a transaction, saidanalyser being operable to identify said outbound and said inbound dataso indicated.
 319. The system of claim 304 wherein said analyser islocated on each of said one or more workstations.
 320. The system ofclaim 304 wherein said application is a web browser.
 321. The system ofclaim 320 wherein said analyser is a plug-in module of said web browser.322. The system of claim 321 wherein said web browser is Microsoft'sInternet Explorer and said analyser is a Browser Helper Object.
 323. Thesystem of claim 304 wherein said application is an e-mail client. 324.The system of claim 323 wherein said analyser is a plug-in module ofsaid e-mail client.
 325. The system of claim 324 wherein said e-mailclient is Microsoft's Outlook e-mail client and said analyser is aMicrosoft Exchange client extension.
 326. The system of claim 304wherein said network comprises a server and said analyser is located ata point on said network intermediate said one or more workstations andsaid server, or said analyser is located at said server.
 327. The systemof claim 304 wherein said computer network to which said one or moreworkstations are adapted for connection is a public computer network,and wherein said one or more workstations together form a privatecomputer network.
 328. The system of claim 304 further comprising asupervisor workstation, said policy data being accessible by saidsupervisor workstation, such that a user of said supervisor workstationcan edit said policy data.
 329. A method for managing informationcomprising the steps of: providing one or more workstations adapted forconnection to a computer network, each workstation having a memory;providing an application stored in said memory of each workstation fortransmitting outbound data to said network and receiving inbound datafrom said network; providing policy data, containing rules for thetransmission of outbound data that may be part of a transaction; andanalysing at least said outbound data to identify, with reference tosaid rule of said policy data, transaction data that may be part of atransaction; determining, in accordance with said rules of said policydata, whether the transmission of said transaction data would satisfysaid rules; controlling transmission of said transaction data by saidapplication in dependence on the determination made in said determiningstep.
 330. The method of claim 329, wherein said controlling stepincludes said transaction data being either, transmitted, nottransmitted, or sent to an approver who determines whether or not totransmit the transaction data.
 331. The method of claim 330 furthercomprising the steps of: identifying in said data that may be part of atransaction, data that needs approval; referring said data that needapproval to one or more approvers for approval; and monitoring whetheror nor approval is received from said one or more approvers; and whereinin said controlling step, the transmission of said transaction datadepends on whether or not approval is received from said one or moreapprovers.
 332. The method of claim 331 wherein said analysing stepincludes identifying said transaction data that needs approval bydetermining the nature of said transaction data and checking said rulesof said policy data, said rules of said policy data defining whether ornot approval is needed in dependence on the determined nature of saidtransaction data.
 333. The method of claim 331 wherein said analysingstep includes determining the nature of said transaction data byidentifying at least one of the identity of the transmitter of saiddata, the identity of the intended recipient of said data, theworkstation from which said data is to be transmitted, the sum for whicha transaction is to be made, and the account from which a transaction isto be made.
 334. The method of claim 331 wherein said analysing stepincludes determining the nature of said transaction data that needsapproval and selecting said one of said one or more approvers independence on that determination.
 335. The method of claim 334 whereinsaid analysing step includes determining the nature of said transactiondata that needs approval by identifying at least one of the identity ofthe transmitter of said data, the identity of the intended recipient ofsaid data, the work station from which said data is to be transmitted,the sum for which a transaction is to be made, and the account fromwhich the transaction is to be made.
 336. The method of claim 329wherein said analysing step includes determining whether a secure linkhas been negotiated between said application and a remote site on saidnetwork, and identifying said outbound data or said inbound data astransaction data, if it is transmitted on a secure link.
 337. The methodof claim 336 wherein said network is the Internet, and said rules ofsaid policy data define the addresses of web sites or e-mail accountsthat negotiate secure links for the transmission of data but which areknown not to be eCommerce sites or accounts, and said analysing stepincludes disregarding said outbound data transmitted to those web sitesor accounts or said inbound data received from those web sites oraccounts, such that no approval is required.
 338. The method of claim329 wherein said analysing step includes identifying transaction data byreference to said rules of said policy data, said rules of said policydata defining the addresses of known eCommerce web sites and e-mailaccounts.
 339. The method of claim 329 wherein said analysing stepincludes identifying credit card numbers in said outbound data or saidinbound data, and identifying outbound data or inbound data thatcontains a credit card number as transaction data.
 340. The method ofclaim 339 wherein said policy data specifies pre-determined credit cardnumbers that can never be transmitted.
 341. The method of claim 329wherein said analysing step includes identifying transaction data byreference to said rules of said policy data, said rules of said policydata defining one or more of pre-determined digital certificates,account codes, pre-determined keywords, pre-determined names andaddresses and embedded codes.
 342. The method of claim 329 wherein saidanalysing step includes detecting an embedded code in said inbound data,said embedded code having been placed in said inbound data to mark saidinbound data as transaction data.
 343. The method of claim 329 furthercomprising the step of providing a user of said application with aselector to indicate said outbound and said inbound data that is part ofa transaction, said analysing step including identifying selectedoutbound and inbound data.
 344. The method of claim 329 wherein saidanalysing step is performed at said one or more workstations.
 345. Themethod of claim 329 wherein said application is a web browser.
 346. Themethod of claim 345 wherein said analysing step is a plug-in module ofsaid web browser.
 347. The method of claim 346 wherein said web browseris Microsoft's Internet Explorer and said plug0in module is a BrowserHelper Object.
 348. The method of claim 329 wherein said application isan e-mail client.
 349. The method of claim 348 wherein said analysingstep is performed by a plug-in module of said e-mail client.
 350. Themethod of claim 349 wherein said e-mail client is Microsoft's Outlooke-mail client and said analyser is a Microsoft Exchange clientextension.
 351. The method of claim 329 wherein said network comprises aserver and said analyser is located at a point on said networkintermediate said one or more workstations and said server, or saidanalyser is located at said server.
 352. The method of claim 329 whereinsaid computer network to which said one or more workstations are adaptedfor connection is a public computer network, and wherein said one ormore workstations together form a private computer network.
 353. Themethod of claim 329 further comprising the step of providing asupervisor workstation, said policy data being accessible by saidsupervisor workstation, such that a user of said supervisor workstationcan edit said policy data.
 354. A computer program product, forcontrolling a computer to manage information, said computer beingconnected to a public network and having access to policy datacontaining rules for the transmission to the public network of outbounddata that may be part of a transaction, comprising: a recording mediumreadable by the computer, having program code recorded thereon whichwhen executed on said computer configures the computer to: analyse, inconjunction with an application running on the computer that is operableto transmit outbound data to the public network and receive inbound datafrom the public network, at least said outbound data to identify, withreference to said rules of said policy data, transaction data that maybe part of a transaction to determine, in accordance with said rules ofsaid policy data, whether the transmission of said transaction datawould satisfy said rules; and to control the computer to control thetransmission of said transaction data by said application in dependenceon the determination made by said analyser.
 355. The computer programproduct of claim 354 wherein said program code when executed on saidcomputer is operable to control the computer such that said transactiondata is either, transmitted, not transmitted, or sent to an approver whodetermines whether or not to transmit the transaction data.
 356. Thecomputer program product of claim 355 wherein the program code whenexecuted on said computer is further operable to identify in said datathat may be part of a transaction, data that needs approval; refer saiddata that needs approval to one or more approvers for approval, andmonitor whether or not approval is received from said one or moreapprovers; and wherein the transmission of said transaction data by saidapplication depends on whether or not approval is received from said oneor more approvers;
 357. The computer program product of claim 356wherein said program code when executed on said computer is furtheroperable to identify said transaction data that needs approval bydetermining the nature of said transaction data and checking said rulesof said policy data, said rules of said policy data defining whether ornot approval is needed in dependence on the determined nature of saidtransaction data.
 358. The computer program product of claim 356 whereinsaid program code when executed on said computer is further operable todetermine the nature of said transaction data by identifying at leastone of the identity of the transmitter of said data, the identity of theintended recipient of said data, the computer in the private networkfrom which said data is to be transmitted, the sum for which atransaction is to be made, and the account from which a transaction isto be made.
 359. The computer program product of claim 356 wherein saidprogram code when executed on said computer is further operable todetermine the nature of said transaction data that needs approval andselect said one of said one or more approvers in dependence on thatdetermination.
 360. The computer program product of claim 359 whereinsaid program code when executed on said computer is operable todetermine the nature of said transaction data that needs approval byidentifying at least one of the identity of the transmitter of saiddata, the identity of the intended recipient of said data, the computerin the private network from which said data is to be transmitted, thesum for which a transaction is to be made, and the account from whichthe transaction is to be made.
 361. The computer program product ofclaim 354 wherein said program code when executed on said computer isoperable to determine whether a secure link has been negotiated betweensaid application and a remote site on said public network, and toidentify said outbound data or said inbound data as transaction data, ifit is transmitted on a secure link.
 362. The computer program product ofclaim 361 wherein said public network is the Internet, and said rules ofsaid policy data define the addresses of web sites or e-mail accountsthat negotiate secure links for the transmission of data but which areknown not to be eCommerce sites or accounts, and said program code whenexecuted on said computer is operable to disregard said outbound datatransmitted to those web sites or accounts or said inbound data receivedfrom those web sites or accounts, such that no approval is required.363. The computer program product of claim 354 wherein said program codewhen executed on said computer is operable to identify transaction databy reference to said rules of said policy data, said rules of saidpolicy data defining the addresses of known eCommerce web sites and thee-mail accounts.
 364. The computer program product of claim 354 whereinsaid program code when executed on said computer is operable to identifycredit card numbers in said outbound data or said inbound data, and toidentify outbound data or inbound data that contains a credit cardnumber as transaction data.
 365. The computer program product of claim364 wherein said policy data specifies pre-determined credit cardnumbers that can never be transmitted.
 366. The computer program productof claim 354 wherein said program code when executed on said computer isoperable to identify transaction data by reference to said rules of saidpolicy data, said rules of said policy data defining one or more ofpre-determined digital certificates, account codes, pre-determinedkeywords, pre-determined names and addresses and embedded codes. 367.The computer program product of claim 354 wherein said program code whenexecuted on said computer is operable to detect an embedded code in saidinbound data, said embedded code having been placed in said inbound datato mark said inbound data as transaction data.
 368. The computer programproduct of claim 354 further comprising, a selector, recorded on saidrecording medium, said selector being operable to select data in saidoutbound and said inbound data that is part of a transaction in responseto input from a user, said program code when executed on said computerbeing operable to identify said outbound and said inbound data soselected.
 369. The computer program product of claim 354 wherein saidprogram code is executable at said computer.
 370. The computer programproduct of claim 354 wherein said application is a web browser.
 371. Thecomputer program product of claim 370 wherein said program code whenexecuted on said computer is a plug-in module of said web browser. 372.The computer program product of claim 371 wherein said web browser isMicrosoft's Internet Explorer and said plug-in module is a BrowserHelper Object.
 373. The computer program product of claim 354 whereinsaid application is an e-mail client.
 374. The computer program productof claim 373 wherein said program code when executed on said computer isa plug-in module of said e-mail client.
 375. The computer programproduct of claim 374 wherein said e-mail client is Microsoft's Outlooke-mail client and said plug-in module is a Microsoft Exchange clientextension.
 376. The computer program product of claim 354 wherein saidpublic network includes a server and said program code is executable ata point on said network intermediate said computer and said server, orsaid program code is executable at said server.
 377. An informationmanagement system comprising: one or more workstations adapted forconnection to a computer network, each workstation having a memory; anapplication stored in said memory of each workstation for receiving atleast inbound data from said network; an analyser, said analyser beingoperable in conjunction with said application to monitor said inbounddata and to identify in at least said inbound data, signed data that hasbeen digitally signed with a digital certificate, to extract one or moredetails of said signed data and to determine whether or not verificationis required for said digital certificate; policy data, accessible bysaid analyser, containing rules which define whether or not verificationis required for said digital certificate; and wherein said analyserdetermines whether or not verification is required for said digitalcertificate in dependence on said rules of said policy data and independence on said one or more details of said signed data extracted bysaid analyser.
 378. The system of claim 377 wherein said verificationfor said digital certificate includes determining whether said digitalcertificate has been revoked.
 379. The system of claim 378 wherein saidanalyser is further operable to determine whether said signed data ispart of an eCommerce transaction, and if it is, to determine the amountof money that is promised in that eCommerce transaction, wherein saidverification for the digital certificate also includes determiningwhether said digital certificate can be taken as a guarantee ofreceiving the amount of money promised in said eCommerce transaction.380. The system of claim 377 wherein said analyser is operable toextract as one or more details of said signed data, one or more of saiddigital certificate holder's identity, the expiry date of said digitalcertificate, the issue number of said digital certificate, and thedomain name from which the signed data was received, and wherein saidrules of said policy file define whether or not verification for saiddigital certificate is required in dependence on the one or more detailsextracted by said analyser.
 381. The system of claim 377 wherein saidanalyser is operable to determine whether or not an eCommercetransaction is occurring, and to extract, as one or more details of saidsigned data, the amount of any transaction being made with said digitalcertificate, the account code from which any payment is being made, acredit card number, one or more indicators of the nature of thetransaction, and wherein said rules of said policy file define whetheror not verification is required for a digital certificate in dependenceon the one or more details extracted by said analyser.
 382. The systemof claim 381 further comprising a data repository in which, digitalcertificates used to digitally sign any previously received signed dataor sufficient decriptive data to identify any such digital certificates,and transaction data describing any previous transactions made withthose digital certificates are stored, said transaction data being atleast one or more of the date of any previous transactions made with adigital certificate, and the amount of any previous transaction madewith that digital certificate, and wherein said rules of said policyfile define whether or not verification for said digital certificate isrequired in dependence on said transaction data.
 383. The system ofclaim 377 further comprising a data repository, accessible by saidanalyser, wherein said analyser is operable to identify any digitalcertificates that are used to digitally sign signed data in at leastsaid inbound data, and to cause any such digital certificates, orsufficient descriptive data to identify such digital certificates to bestored in said data repository.
 384. The system of claim 383 whereinsaid analyser is operable, to record the results of any verification foran digital certificate in said data repository together with saiddigital certificate or together with said descriptive data.
 385. Thesystem of claim 384 wherein said analyser is operable, if it identifiesa digital certificate in said inbound data, to determine whether saiddigital certificate has been previously stored in said data repository,or whether said descriptive information identifying said digitalcertificate has been stored in said data repository, and if said digitalcertificate has been previously stored, to look-up the results of anyprevious verification of whether said digital certificate has beenrevoked, wherein said analyser determines whether or not to verify ifsaid digital certificate has been revoked in dependence on said resultsof any previous verification of whether said identified digitalcertificate has been revoked.
 386. The system of claim 377 wherein saidanalyser is further operable to verify whether or not a digitalcertificate has been revoked, and wherein said application is operableto prevent said inbound data being viewed by a user of said applicationif said analyser determines that said digital certificate has beenrevoked.
 387. The system of claim 377 wherein said analyser is furtheroperable to verify whether or not a digital certificate has beenrevoked, and said application is operable to notify a user of saidapplication that said inbound data is not to be relied upon if saidanalyser determines that said digital certificate has been revoked. 388.The system of claim 377 wherein said analyser is located on each of saidone or more workstations.
 389. The system of claim 377 wherein saidapplication is a web browser.
 390. The system of claim 389 wherein saidanalyser is a plug-in module of said web browser.
 391. The system ofclaim 390 wherein said web browser is Microsoft's Internet Explorer andsaid analyser is a Browser Helper Object.
 392. The system of claim 377wherein said application is an e-mail client.
 393. The system of claim392 wherein said analyser is a plug-in module of said e-mail client.394. The system of claim 393 wherein said e-mail client is Microsoft'sOutlook e-mail client and said analyser is a Microsoft client extension.395. The system of 377 wherein said network comprises a server, and saidanalyser is located at a point on said network intermediate said one ormore workstations and said server, or said analyser is located at saidserver.
 396. The system of claim 377 wherein said computer network towhich said one or more workstations are adapted for connection is apublic computer network, and wherein said one or more workstationstogether form a private computer network.
 397. The system of claim 377further comprising a supervisor workstation, said policy data beingaccessible by said supervisor workstation, such that a user of saidsupervisor workstation can edit said policy data.
 398. A method ofmanaging information comprising the steps of: providing one or moreworkstations adapted for connection to a computer network, eachworkstation having a memory; providing an application stored in saidmemory of each workstation for receiving at least inbound data from saidnetwork; providing policy data, containing rules which define whether ornot verification is required for a digital certificates used todigitally sign signed data received in said inbound data; identifying inat least said inbound data, signed data that has been digitally signedwith a digital certificate; extracting one or more details of saidsigned data; and determining whether or not verification is required forsaid digital certificate in dependence on said rules of said policy dataand in dependence on said one or more details of said signed dataextracted in said extracting step.
 399. The method of claim 398 whereinsaid verification for the digital certificate includes determiningwhether the digital certificate has been revoked.
 400. The method ofclaim 399 further comprising the step of determining whether said signeddata is part of an eCommerce transaction, and if it is, determining theamount of money that is promised in that eCommerce transaction, whereinsaid verification for the digital certificate also includes determiningwhether said digital certificate can be taken as a guarantee ofreceiving the amount of money promised in said eCommerce transaction.401. The method of claim 398 wherein said one or more details of saidsigned data extracted in said extracting step, include one or more ofsaid digital certificate holder's identity, the expiry date of saiddigital certificate, the issue number of said digital certificate, andthe domain name from which the signed data was received, and whereinsaid rules of said policy file define whether or not verification forsaid digital certificate is required in dependence on the one or moredetails.
 402. The method of claim 398 further comprising the step ofdetermining whether or not an eCommerce transaction is occurring, and ifit is, extracting in said extracting step, as one or more details ofsaid inbound data, the amount of any transaction being made with saiddigital certificate, the account code from which any payment is beingmade, a credit card number, one or more indicators of the nature of thetransaction, and wherein said rules of said policy file define whetheror not verification is required for a digital certificate in dependenceon said one or more details.
 403. The method of claim 402 furthercomprising the step of providing a data repository in which digitalcertificates used to digitally sign any previously received signed dataor sufficient descriptive data to identify any such digitalcertificates, and transaction data describing any previous transactionsmade with those digital certificates are stored; said transaction databeing at least one or more of the date of any transactions made with adigital certificate, and the amount of any transaction made with thatdigital certificate, and wherein said rules of said policy file definewhether or not verification for said digital certificate is required independence on said transaction data.
 404. The method of claim 398further comprising the steps of identifying digital certificates used tosign signed data in said inbound data or digital certificatestransmitted in said inbound data and storing said digital certificatesor sufficient descriptive data to identify said digital certificates insaid data repository.
 405. The method of claim 404 further comprisingthe steps of recording the results of any verification for an digitalcertificate in said data repository together with said digitalcertificate.
 406. The method of claim 405 further comprising the step ofdetermining whether said digital certificate has been previously storedin said data repository, and if it has been previously stored, tolook-up the results of any previous verification for said digitalcertificate, wherein said step of determining whether or notverification is required for said digital certificate is dependent onsaid results of any previous verification for said digital certificate.407. The method of claim 398 further comprising the steps of determiningwhether or not a digital certificate has been revoked, and preventingsaid inbound data being viewed by a user of said application if saididentified digital certificate has been revoked.
 408. The method ofclaim 398 further comprising the steps of determining whether or not adigital certificate has been revoked, and notifying a user of saidapplication that said inbound data is not to be relied upon if saiddigital certificate has been revoked.
 409. The method of claim 398wherein said steps of identifying a digital certificate, extracting oneor more details from said signed data and determining whether or notverification is required are performed at said one or more workstations.410. The method of claim 398 wherein said application is a web browser.411. The method of claim 410 wherein said steps of identifying a digitalcertificate, extracting one or more details from said signed data anddetermining whether or not verification is required are performed by aplug-in module of said web browser.
 412. The method of claim 411 whereinsaid web browser is Microsoft's Internet Explorer and said plug-inmodule is a Browser Helper Object.
 413. The method of claim 398 whereinsaid application is an e-mail client.
 414. The method of claim 413wherein said steps of identifying a digital certificate, extracting oneor more details from said signed data and determining whether or notverification is required are performed by a plug-in module of saide-mail client.
 415. The method of claim 416 wherein said e-mail clientis Microsoft's Outlook e-mail client and said plug-in module is aMicrosoft Exchange client extension.
 416. The method of claim 398wherein said network comprises a server, and said steps of identifying adigital certificate, extracting one or more details from said signeddata and determining whether or not verification is required areperformed at a point on said network intermediate said one or moreworkstations and said server, or said steps of identifying a digitalcertificate, extracting one or more details from said signed data anddetermining whether or not verification is required are performed atsaid server.
 417. The method of claim 398 wherein said computer networkto which said one or more workstations are adapted for connection is apublic computer network, and wherein said one or more workstationstogether form a private computer network.
 418. The method of claim 398further comprising providing a supervisor workstation, said policy databeing accessible by said supervisor workstation, such that a user ofsaid supervisor workstation can edit said policy data.
 419. A computerprogram product for controlling a computer connected to a public networkto manage information, said computer having access to policy datacontaining rules which define whether or not verification is requiredfor a digital certificate used to digitally sign signed data received ininbound data from the public network, comprising: a recordable mediumreadable by the computer, having program code recorded thereon whichwhen executed on said computer configures said computer to: analyse, inconjunction with an application running on the computer that is operableto receive at least inbound data from the public network, signed datathat has been digitally signed with a digital certificate, to extractone or more details of said signed data; to determine whether or notverification is required for said digital certificate in dependence onsaid rules of said policy data and in dependence on the one or moreextracted details of said signed data; and to control the application independence on the determination.
 420. The computer program product ofclaim 419 wherein said verification for the digital certificate includesdetermining whether the digital certificate has been revoked.
 421. Thecomputer program product of claim 420 wherein said program code whenexecuted on said computer is further operable to determine whether saidsigned data is part of an eCommerce transaction, and if it is, todetermine the amount of money that is promised in that eCommercetransaction, wherein said verification for the digital certificate alsoincludes determining whether said digital certificate can be taken as aguarantee of receiving the amount of money promised in said eCommercetransaction.
 422. The computer program product of claim 419 wherein saidone or more details of said signed data, include one or more of saiddigital certificate holder's identity, the expiry date of said digitalcertificate, the issue number of said digital certificate, and thedomain name from which the signed data was received, and wherein saidrules of said policy file define whether or not verification for saiddigital certificate is required in dependence on the one or moredetails.
 423. The computer program product of claim 419 wherein saidprogram code when executed on said computer is further operable todetermine whether or not an eCommerce transaction is occurring, and ifit is, to extract as one or more details of said signed data, the amountof any transaction being made with said digital certificate, the accountcode from which any payment is being made, a credit card number, one ormore indicators of the nature of the transaction, and wherein said rulesof said policy file define whether or not verification is required forsaid digital certificate in dependence on said one or more details. 424.The computer program product of claim 423 wherein the program code whenexecuted on said computer is further operable to control the computer torecord digital certificates used to digitally sign any signed datareceived in said inbound data or sufficient descriptive data to identifyany such digital certificates, and transaction data describing anytransactions made with those digital certificates in a data repositorysuch that a record is maintained of transactions made with a digitalcertificate; said transaction data being at least one or more of thedate of any transactions made with a digital certificate, and the amountof any transaction made with that digital certificate, and wherein saidrules of said policy file define whether or not verification for saiddigital certificate is required in dependence on said transaction data.425. The computer program product of claim 419 wherein said program codewhen executed on said computer is further operable to control thecomputer to store digital certificates used to sign signed data in saidinbound data or digital certificates transmitted in said inbound dataand storing said digital certificates or sufficient descriptive data toidentify said digital certificates in a data repository.
 426. Thecomputer program product of claim 425 wherein said program code whenexecuted on said computer is further operable control the computer torecord the results of any verification for an identified digitalcertificate in said data repository together with said identifieddigital certificate.
 427. The computer program product of claim 426wherein said program code when executed on said computer is operable todetermine whether said identified digital certificate has beenpreviously stored in said data repository, and if it has been previouslystored, to look-up the results of any previous verification for saididentified digital certificate, wherein the determination of whether ornot verification is required for said identified digital certificate isdependent on said results of any previous verification for saididentified digital certificate.
 428. The computer program product ofclaim 419 wherein said program code when executed on said computer isoperable to determine whether or not a digital certificate has beenrevoked, and control said application to prevent said inbound data beingviewed by a user of said application if said identified digitalcertificate has been revoked.
 429. The computer program product of claim419 wherein said program code when executed on said computer is operableto determine whether or not a digital certificate has been revoked, andto control said application to notify a user of said application thatsaid inbound data is not to be relied upon if said identified digitalcertificate has been revoked.
 430. The computer program product of claim419 wherein said program code is executable at said computer.
 431. Thecomputer program product of claim 419 wherein said application is a webbrowser.
 432. The computer program product of claim 431 wherein saidprogram code when executed on said computer is a plug-in module of saidweb browser.
 433. The computer program product of claim 432 wherein saidweb browser is Microsoft's Internet Explorer and said plug-in module isa Browser Helper Object.
 434. The computer program product of claim 419wherein said application is an e-mail client.
 435. The computer programproduct of claim 434 wherein said program code when executed on saidcomputer is a plug-in module of said e-mail client.
 436. The computerprogram product of claim 435 wherein said e-mail client is Microsoft'sOutlook e-mail client and said plug-in module is a Microsoft Exchangeclient extension.
 437. The computer program product of claim 419 whereinsaid network includes a server and said program code is executable at apoint on said network intermediate said computer and said server, orsaid program code is executable at said server.